Tackling Technical Debt with LimaCharlie’s Maxime Lamothe-Brassard

This is Textron tv. Hey guys. Thanks, Viro.

We're here with Maxine Lath, brasad of CEO for Lima, Charlie, and we're talking about technical debt. We all have it, but maybe it's just spiraling outta control and contributing to our security was, Hey, Maxine, welcome the show. Hi.

Very happy to be here. We'll never escape technical debt entirely. It seemed like that's not a goal that we can possibly get to, but who knows?

But, um, it feels like it is outta control. What's driving that? What's going on?

Do we just have too much of what might otherwise be described as a good thing? Yeah, you know, no, I, I think that's actually, I actually, that that's sort of the, the, like, the perfect way of, uh, of thinking about it, right? Like technical debt.

At the end of the day, I see it as the other part of getting good things, uh, and the more good things we have, meaning, you know, solutions to various things, right? More systems we have, um, the more, there's the other side of the metal that comes with it, right? Uh, for me, the, the kind of mental mapping is sort of, you know, if you own many different properties, maybe right, many different houses, well, you know, maybe you can host more people and maybe you can, uh, you know, like rent.

Some of them, maybe you can have events, but it also means that the other side of that metal is you need to do the upkeep and you need to pay the taxes, and you need to do all of the things. So I think there are just a natural, uh, natural side of the metal to anything that we do that, that touches, uh, it in general, I think as they say, the road to hell is paved with good intentions. And what kind of happens is, um, people decide that, well, I can't fix that vulnerability, or I can't get at that particular issue right now.

So what we're gonna leverage Agile and all our DevOps stuff, and I'll get to that next time, I swear, and then it slides off the list because other things get added to the list. And then before you know it, you've got some sort of known vulnerability that hasn't been addressed in a year, and then you wake up one morning and the bad guys have discovered it and all, how breaks loose? Um, how do we kinda wrap our arms around this in a, in a way that maybe would bring a little more, shall we say, adult supervision to this process?

Um, yeah. So I, I think the, like the, the core thing to keep in mind is that, uh, cybersecurity is sort of dealing with a lot of this debt of this tech debt. And we need to find a different way of, uh, of dealing with the, the source of this data.

Meaning we have, uh, you know, we have a ton of different things that we need to secure. And as you say, you know, something comes up and we need to go and start securing it, and, you know, maybe we put some control in place, uh, maybe, maybe we buy some new product or some open source thing. And, uh, the, the kind of core difficulty that cyber security has is that, um, we seem to only be accumulating those.

Um, it seems like what we're doing is we're really just producing very narrow solutions to these problems without ever kind of going back at a really high level and saying, okay, now that we have, you know, these hundred different kind of patches right on, on, uh, whether it's detection, engineering, or vulnerability around like products or like whatever kind of type of tech that to go back and say, okay, now that we've done this and we've done this for, I dunno, five years, 10 years, sometimes, um, is there a way that we can rethink about how we're covering those in, uh, in a different way? In a way that five years ago we couldn't see, right? We kind of saw a hundred different individual problems, but now we are 10 years later and we have ways to address all of these using different solutions.

So in my mind, the, the tech debt problem in insecurity isn't necessarily a question of finding the way or the time to go and pay all of that debt individually, but rather it's, uh, I guess it's like restructuring that debt, right? And saying like, Hey, it turns out that these a hundred different problems that we thought we had, really, nowadays, you know what? It's super boring now because we figure it out like M-F-A-M-F-A is the solution to this, and we can, you know, get rid of a bunch of those without just continuously kind of trying to individually pay that debt and, and, and introduce more single solutions that we know we're gonna have to pay individually in the next 10 years to.

So in theory, there are strategic moves you can make that would wipe out a large amount of the technical debt versus trying to go in and fix every vulnerability that is known to mankind. Is that where we're pointing at? Yes, that's, I think that's exactly right.

Yeah. Um, when we think about all of this technical debt, I think the issue that comes to mind that drives everybody crazy is there'll be a breach and, and part of the forensics and the investigation thereof, it will be determined that by golly, there was a patch for that particular thing that was available a year ago, and nobody got around and implementing it, and therefore that's why we got whacked. So how do we kind of keep track of what is, uh, a available to be patched?

'cause I think there's just a huge volume of this stuff. And then b, it seemed like part of the challenge is, is we're also afraid to patch because we think things will get broken if I play with things. So we're kind of like, damned if we do and damned if we don't.

So how do we manage this? Yeah. And, and I think that's a perfect example of, uh, of this kind of restructuration, right?

So here, here's to pick on that specific example of let's say, Hey, we're, you know, we know that we have to patch these things, but we are very afraid that if we do something wrong, it's gonna happen. That's a perfectly legitimate fear, and there's one way to go at it, and it's to say, you know what? Well, we're, you know, right, for compliance, right?

We just, we just have to go and do it, and we're gonna go and individually spend the time paying that debt on all these individual, you know, uh, uh, services that we need to, we need to patch and all that. But there's another way to look at it, and it's to say, Hey, there's a bunch of, of DevOps types of, uh, learnings that we've done in the past 10 years. One of them, uh, is, you know, around containerization.

Look, it's not, it's not a magic wand that solves all the problems, but there's a lot of, um, there's a lot of worries around patching that has, uh, been really lessened in importance over the, over, you know, the last, let's say like five years, um, from people that are building their solutions around containers, around upstream, well-maintained containers from, you know, well-known distributions. And in such a way that if you go and decide, you know, what we're, we're going to, instead of just patching, we're going to, you know, port those things, um, and, and start using those processes for all of the services or, you know, the, the software that we deploy, then you end up really saving a lot of time on your side because now you don't, you're never in a question of like, I need to patch this server running this thing, but instead it becomes a, like, yeah, every week we, you know, we rebuild onto those, well-maintained, uh, you know, long-term serve, uh, uh, long-term LTS solutions, you know, from upstream containers that are well-maintained, and that problem goes away because we don't have a server running the thing. We are just continuously be rebuilding those and continuously updating those in the containers.

And so it just, you know, those problems kind of, they don't fully go away, but a lot of it does go away, Right? But there's a lot of junk in those containers that's still vulnerable. Oh, yeah.

Oh, um, yeah. You just have to remember to update what was in that container versus just responding it, right? No, that's correct.

That's correct. And I think that's where a lot of the modern, uh, SaaS solutions or cloud providers are actually doing a really good job about this as well, right? Of being able to scan within those containers and being able to report the status of all of those.

I know we, we certainly, we use like, uh, Vanta as a solution. Um, and I, I know there's, there's several others that are extremely valuable in terms of, uh, helping to prioritize and know when things need to re be rebuilt and redeployed and all that. What's your sense of, uh, the folks who are driving security these days?

Can we make it more comfortable for them to, uh, automatically upgrade or apply a patch to something without worrying about breaking something? I think sometimes there's low level stuff that, you know, if it does break, the odds are low, and B, the the fix is easy, and c, the risk of the security breach is much higher than the cost of the downtime. So why not That?

That's right. That's right. I think there's also, um, there's also combinations of strategic technologies that, again, make your life a lot easier, right?

Um, what I mean by this is, um, if you are looking at, uh, so first, I guess, you know, good processes, right? Of having everything being like tested. Obviously everybody that builds software has very thorough testing, uh, behind it.

Um, it's tongue in cheek, clearly. No, I was crossing my fingers and toes there, but yeah, I'm with you. But, but those are things that, that really, you know, they save your ass, uh, in terms of, of time when it comes to doing these things like continuous rebuilding, right?

Where you don't have to spend engineering time going and testing that. And the other thing is modern languages. So I think if you're building software, particularly, I guess I'm kind of coming from that perspective here, but if you're building software, um, there's, uh, decisions that will have a very big impact, right?

Like, hey, if you're, if you're building things on, um, on, you know, a JavaScript stack, um, you know, good luck, uh, you know, wish you all the best, uh, but it's gonna be, you're gonna have a rough time ahead of you. Um, on the flip side, uh, I know, I think there's several other languages like that we use, uh, Golan quite a bit. And, you know, internally we are at the point where we are happy with, uh, uh, you know, almost blindly updating dependencies because of the, the reliability of the language, the compiler, the testing.

And so this whole rebuilding becomes almost just a thing that happens behind the scene. Um, so, so I think, yeah, a a lot of those strategic decisions really have a really, really big impact. In theory, I could reduce my technical debt by just wiping out 1, 2, 3, 4 platforms maybe.

Um, we have a lot of platforms. People seem to be reluctant to give them up. They're almost the equivalent of platform huggers.

Um, how do we make this call about, you know, am I too attached to a particular platform and I don't wanna retire the app on it, and therefore I'm gonna become a proverbial, you know, for lack of a better phrase, slave to updating it forever. Or can I replace this thing and what, what, when do I make that call? Yeah.

So, you know, look, I, I have a pretty, I have a pretty strong opinion on that topic, uh, very clearly, you know, because of what we're doing at Le Charlie. But I think, I think that is one of the core difficulties that the cybersecurity industry has, is the accumulation of solutions, right? Uh, kind of hinted at it a little bit earlier, meaning, um, you know, 20 years ago, uh, you know, kind of pick your Gartner, you know, hot term around cybersecurity was very, very, uh, cutting edge and important.

And every year there's more of those terms, right? Those acronyms that are very important in all cutting edge. But after 20 years, we have to be able to retire some.

And I think that is sort of the, the biggest habit that the cybersecurity industry has to get out of, which is the accumulation of those, and to rethink their security posture, not in terms of very narrow individual solutions where, um, you know, where the, the, it's kind of a, uh, like a blinking red light solution, meaning like, Hey, you don't have to understand anything, like if this light blinks red, you know, you've been hacked, kind of thing. But instead, rethink all of this in terms of the things that you need to accomplish as part of your security program. It's not about I need to have x, it's about I need to be able to detect, you know, uh, an attacker that does X, y, or Z and respond to those things.

And when you get into that habit of thinking functionally, that is when you kind of realize that, you know, of those 20 acronyms that you have, that you have to maintain, that you have to have people that know about it, that you're very dependent of. Uh, a lot of those use cases over the last 20 years have kind of become features and not, and not solutions themselves, and you're able to really kind of bring that down and bring it down to a level where you know what you're defending against, you know, how you're defending against that. There's no magic here, right?

It's, it's kind of a, a, it's a, it's a mature defense process. So are you saying that we have like a hoarding issue in it, and maybe you all need some therapy? Is that where you're going?

Yeah. Yes. But I understand why, uh, right?

Like, it's, if, if you think, like historically in cybersecurity, uh, you know, when I started in like early two thousands, uh, I, I kind of always joked that cybersecurity was the two guys in the hoodies in a basement, and nobody knew what they were doing, but they were doing security, right? Like a lot of hand waving. And over the years, you know, we've gotten way better.

But I think the foundation of all those things in security were so, uh, you know, obscure and like, oh, you need to have that thing because somehow it protects you. And there's a couple of people that understand why that we kind of just got, got into that habit. And, uh, and yeah, we need to break, break the cycle of hoarding.

All right? You heard it here, folks. The more things you have, the more things you have to protect, the more likely it becomes you're gonna have a problem.

So technical debt sounds like a fancy nice word, but in reality it's just trouble. Hey, Maxine, thanks for being on the show. Thank you very much.

Bye. Pleasure. All right.

Back to you guys in the studio.