Chapters
Shownotes Transcript
Hello, this is Katalin Kampano. Welcome to another sponsored interview on the Risky Business News Podcast. Today, our guest is Travis McPeak, the co-founder and CEO of Resourcely. Welcome, Travis. Hey, how's it going? Glad to have you back, Travis. Now, Resourcely is a DevSecOps company that lets developers pin up cloud infrastructure that is secure by default.
It's a great way to avoid common security issues like misconfigurations, vulnerabilities, out-of-date server images, and so on. Yes. Now, Travis, you've been in the DevSecOps field for almost 15 years now. How has the perception around misconfigurations changed? And how has the perception changed around the security-related work that developers need to perform during their regular duties? Because...
I don't remember in the early days security being a main focus for anyone. Yeah, same here. So I started my career just as we were transitioning from the phase where security was a checkpoint function. As developers were shipping something in a waterfall model, there would be a security sign-off phase. So when I started my career, we were doing that. And then very early, we were moving to DevSecOps, I think in large part because of the movement
the move from point in time software releases to continuous deployment in a SaaS model.
When that happened, instead of security saying like, okay, we're going to do the sign off. Now we're doing so much deployment so fast that security is trying to figure out how do they actually get security checkpoints where they want. And in part because of that, basically security used to be security's job. We would go and do an assessment and tell you about risk and maybe make recommendations about shipping your product. But in DevSecOps, we said security is everybody's job.
So now instead of developers just focusing on writing their business app logic and actually helping make products that make the company money,
We've now deputized them and said, you're all security people somewhat. And so you're going to learn about all the kinds of cross-site scripting and exactly how SQL injection works. And my position is that this isn't effective. It's taken developers that should be focused on helping the business and dropped a ton of cognitive load. And they're never going to be particularly effective at this. It doesn't matter how many times you train developers on the nuances of cross-site scripting. It's not a major part of their job. They're going to forget it as soon as the security training is done.
So what do you think was the inflection point when people started thinking more about the work developers need to do on security? Was it when cloud generally exploded across the IT landscape or was it somewhere earlier? So I remember for me the first time I saw the shift and I was actually
So occupied time pre-shift, during shift, and then after shift. So pre-shift, like I said, one of the things that we would do in security is we'd get a hold of the software. We'd do this kind of like thorough review on it. And then we'd kick it back to the engineers that were trying to release it.
During shift, we were responsible for basically fast-moving, continuous deploying SaaS cloud services. So yeah, definitely cloud has added a lot of complexity to this because cloud changed the perimeter. Cloud's made it so that we can move much faster than a traditional IT procurement deployment process could.
And then also SaaS made it so that things are changing much quicker. So if security is going to do a sign-off function, when do they do it? Do they just pick some day and be like, this is the time that we're doing sign-off? So we tried doing that at a job where we were responsible for security in cloud and in SaaS and microservices. We would just pick random times and basically do threat models.
We'd say, tell us about the service as it exists today. What components does it interact with? We do a threat model. And then for us, it was really hard to know, like when do we invalidate this threat model and do another one? So it was very arbitrary. And then at some point in a job after that, we moved to basically like, okay, threat modeling, these kind of code reviews,
They're not very scalable. It's hard to know like point in time when to do it. And what we're going to focus on instead are basically like tools that empower developers to own this security stuff, you know, for themselves without having to become experts. And then also systems that just produce good security without developers having to worry about it. Travis, do developers today consider security a core part of their job or do they still have the view that security needs to be a separate department, like a separate section inside the company?
Because we keep talking about the rise of DevSecOps and how developers aren't really actual security engineers. They just know a little bit of security. But how do you feel about this? You interact with lots of your customers. Would they still prefer security to be its own thing? Or do they prefer to just have better tools like the ones you provide and still dabble a little bit in security?
Yeah, so I think, you know, developers, like most people, there's all kinds of different flavors of them and they have different opinions. You know, developers often are very prideful people. They really take pride in their work and they want to do the right thing. I think we haven't set them up for success by telling them like, hey, you're like the first line responsible for security of your services. It's just too much for them. So I think, you know, the model that I've seen work the best, you know,
First of all, you take as much of the security concerns off of developers as possible by giving them tools that just tools or frameworks or process that set things up correctly. So an example of this that's not my product, for example, is like,
you know, if you use ORM, then you don't have to worry about SQL injection. So that's kind of, you know, that's just no brainer guidance that a developer can implement without having to particularly understand SQL injection. So that's an easy thing. Number two is like basically telling developers about the kinds of risky operations where they should slow down and maybe engage with security. And then number three is, you know, we don't tell them like security is your responsibility. We say,
You care about the quality of your service. Security is like reliability and like general quality. It's part of what makes your service good. These are our recommendations. In general, you should be doing things like keeping libraries up to date, not just for security, but for stability and just general good hygiene. If you don't do that, bad things are going to happen. But not do this kind of relentless training that we do about trying to teach them about all the nuances of security
security vulnerabilities. It doesn't make any sense for them. This is where your product will generally come to help because you just provide something that's secure by default.
But one thing I was wondering is how do you maintain your templates? Because as you've described, the security threat model has evolved over the past few years. So there's obviously a need to update templates with current threats, current misconfigurations. What would be the typical steps of identifying issues with the template or learning of a new misconfiguration and then embedding it in your template and shipping it to customers?
Yeah, that's a great question. So first of all, we can't do secure by default templates for a few reasons. First of all, secure is subjective. So what one company considers secure is different than what another company considers secure. Second, secure is context dependent. So for example, you may be completely fine with certain practices in a test environment that you aren't in prod. Or depending on the kind of data that you're dealing with, you may need
more escalated security policies that aren't appropriate for data stores that aren't handling that kind of sensitive data. So the actual configuration and secure configuration depends on a lot of context. So it's really hard to apply blanket policies and different companies are totally different and have different perspectives on this. So what we do is we actually basically give customers a nice starting place, which is like, here's general pattern for infrastructure that meets best practices,
But on top of that, we enable them to apply what we call guardrails. And guardrails define what good configuration looks like. It's not just for security, by the way. So for example, if somebody is creating a data store, you might want them to have tagged it correctly so that you know who owns it, what kind of data is in there. You might want them to have picked certain engine types that you do or don't use at the company.
you might want them to have picked certain instance types for like cost management. So there's all these kinds of configuration that aren't just security. And the way that we've tackled the
like making them so that they keep going over time is by decoupling the basic pattern. So, you know, what we call a blueprint. The blueprint is just a template. And then on top of that, we apply a lot of correct configuration opinions with guardrails. And the way that we've tackled is by decoupling those. If it were simple enough that you could just have secure by default templates, these things would be open source. They'd be on GitHub. This would be a solved problem and our company wouldn't exist.
So the way we describe it, the template is mainly your responsibility and the guardrails is how customers customize their infrastructure needs, right? Exactly. So let's stay here. One thing I was wondering when preparing the interview was about how you deal with real-time changes in the security ecosystem. Let's pretend we are back in 2015 and everybody finds out that MongoDB is exposed right on the internet with its admin interface.
How would you go to updating your customers that, okay, we've changed this template because we learned there's some major issue with the piece of software? How would you let them know?
Who do you do it at?
So in resourcely, we call these campaigns. A campaign can be obviously driven by a security response like what you just said. We need to go find all of the Mongo instances that are deployed and enable the user to adopt this new property, which is going to make this closed off the Internet. Now, some people think, why don't we just go and make the changes? We're just going to go and apply all of these and get all the mongos off the Internet.
The problem is sometimes the user actually needed it to be on the internet. And they've built their application around that database being internet exposed. They haven't set up the correct other networking controls to allow their application to connect to Mongo, not through the internet. So if you just go make that change, if you're a platform engineer or a security engineer and you just go and make that change,
likelihood is you're going to cause an outage, probably like multiple outages as these applications can't connect to their Mongo instance anymore. So you really want the user participation in these decisions. You want to say, we've identified this Mongo issue. This is the change that we need to make and then work together with your end user to actually make the change at a time when they can pay attention and make sure that the app isn't down.
the last thing you want to do is catch them by surprise. So in resource, we call these campaigns. They can be initiated by a user like an engineering team or a security team.
but with participation from their end user developer customers. So we'll actually help create a pull request. And when that pull request is merged, then the configuration will be applied. And we can also track the progress of those over time. So as little friction as possible. Yeah, yeah, yeah, yeah. So, I mean, I think that, you know, to your earlier question about, you know, how much security should a developer want to do? You know, even for the business, like most businesses exist to produce a product.
And security is a cost center, right? Like we want to have good security so that our customers trust us and that we don't have to drop everything to respond to some horrible security outage. And we don't have, you know, fines and judgments against us and all of these things. But most businesses exist for some other purpose beyond security. And so the trick for a real security person is to provide the right level of security for the business, right? The last thing you want to do is like slow everything down, stop them and whatever. So I think,
What's nice about this approach where it's not just like we've pushed everything on to developers and we asked them to do security without a ton of context on what it is and why it's important. What I'm particularly excited about is just
You cover as much ground as quickly as possible by building nice tools for engineers that allow them to get their job done even faster and then have security baked into it. That's why I think secure by default is such a powerful concept. It's not just because developers don't have to become security experts. It's also because it's the fastest way for them to do whatever they wanted to do for the business. So because you have this ability to build something based on a template, customers stay with your service beyond the need for security? Yeah.
Like let's say they might be deploying something internally. They may not need all the controls you provide, but they like the ability to, as you said, have guardrails around their software. Do you see your service being used for just plain old infrastructure, not necessarily critical infrastructure? Absolutely. Yeah. So part of it is the kind of correct configuration that we can produce.
isn't just for security stuff. It's for cost management, you know, for some compliance, for standards, for reliability, you know, making sure that databases are backed up according to strategy, things like that. Those are all good configuration. That's number one. And number two is, you know, even for things that aren't necessarily critical, you still want them to be configured well, because, you know, most of your infrastructure is probably not critical, but misconfiguration still like really adds up to cost. And also, you know,
The impact of destructive changes. One of the things that we've been seeing is basically users make changes to their infrastructure that causes things like outages, unplanned problems, and just enabling them to take a step back and look carefully at certain changes with guardrails has proven to be quite helpful, not just for security customers, but also engineering customers. Okay. Thanks, Travis. I think that's a great way to end it. Thank you. I appreciate it.
