In today’s episode of the Brains Byte Back podcast, we speak with Mike Starr, Founder and CEO at trackd, a platform that aims to simplify vulnerability management and patch management.
From this episode, you will learn about Starr’s journey from being an NSA engineer to entering the startup world. We also learn about the intriguing story behind the name trackd and how it resonates with both tech enthusiasts and non-nerds alike.
To kick off the show Starr shares how he transitioned from his role as an NSA engineer to the startup world after meeting a brilliant individual at a tech gathering in DC. This encounter led him to work on software-defined networking and eventually paved the way for founding trackd.
Starr then shares his views on some of the worst cybersecurity advice, including the misbelief in the security of air-gapped networks. He emphasizes the need for tailored security approaches that consider the specific context and needs of each organization.
Additionally, he shares the best cybersecurity advice for listeners, which according to him is understanding the problems that need solving and aligning security and IT teams’ efforts. He takes it a step further and advocates that collaborative decision-making, treating humans as humans, and bridging the gap between security and IT tools are essential in this process.
Also, Starr sheds light on the significance of considering the human factor in cybersecurity breaches. He emphasizes the importance of collaboration and empathy between different teams and how vendors can contribute to fostering a more collaborative culture.
And finally shares how trackd aims to expand its network and install base, providing tools and features to eliminate vulnerabilities in enterprises. With a focus on making patching safer and more efficient by aligning it with corporate risk strategies and considering the operators’ perspective.
Mike Starr: My name is Mike Starr. I’m the founder and CEO of Trackd. And what we found is that when most people are trying to fix their software vulnerabilities, they’re crossing their fingers, hoping patches won’t break their sh*t. So, we built a platform that not only unifies vulnerability management and patch management but also provides insights into how patches have affected other people’s systems before you apply them to yours. This allows operators to automate remediation decisions based on quantifiable metrics instead of qualitatively worrying about disruption and safety within arbitrary periods of time.
Samuel Brake Guia: Fantastic. Thanks for joining me today because you have such an interesting background, and I’m really looking forward to exploring it. I understand you’re a former NSA engineer. I’d love to hear how you transitioned from government employment to the startup world.
Mike Starr: Yeah, there’s a really long version of this, but ultimately, I met a wickedly intelligent dude at a nerd barbecue in DC. It’s a big hub for tech folks and data center space, which aligns with my background. This guy was on the forefront of software-defined networking when it was in its infancy and OpenFlow was still a baby. At the same time, I was closing out three major projects at the agency that largely revolutionized how cyber operations networks were built and conducted. But when I tried to push the envelope further, I ultimately got a pat on the head and was told I had done enough, and they needed me to lay low for a bit. So I asked this dude, “Hey man, how do you sell SDN to companies?” and his response was, “Why don’t you just come work for me? And I’ll double your salary.” So I did.
Samuel Brake Guia: That is a fantastic offer. That’s what everyone dreams of. And I want to know what’s the story behind the name Trackd, and I should say for listeners, it’s spelled T R A C K D.
Mike Starr: Yeah, it’s a pretty lame one actually. Initially, when I was doing interviews for this concept, I kept talking about it as an “intelligent vulnerability management lifecycle system,” which is a mouthful. When I went to create the first GitHub repo, I thought, “This is too long to be typing and saying all the time.” So I was like, “What the hell am I actually doing with this thing?” And I thought, “I guess I’m tracking s***.” So I said, “Well, maybe ‘Tracked’ or ‘Tracker’ or something like this.” For those that are Unix nerds, a word with a lowercase “d” at the very end indicates that something is running in the background (a daemon). So I thought, let me be cute and just drop the “E” and we’ll call it “Trackd.” So now, Unix nerds will come up to us and say, “Hey, tell me about Track d,” and then non-nerds will come up to us and say, “Hey, tell me about Trackd.” Funny enough, we consistently get that. So our marketing guy, anytime someone comes up to the booth and says “Trackd,” he’ll be like, “So you’re a big Unix nerd,” and they’re like, “How the hell did you know that?” And so it’s a great icebreaker for people coming up to the booth.
Samuel Brake Guia: That’s a fantastic way of, I suppose, understanding where people are coming from immediately, and I think automatically you know that I’m not a Unix nerd considering that I’ve already jumped into the category of “Trackd.” So I’ve learned something new there as well. That’s awesome. I also want to say one of the things that we want to discuss primarily on today’s show is the prevalence of bad and wrong information about cybersecurity, and I’d love to know what are some of the worst pieces of cybersecurity advice that you’ve ever heard?
Mike Starr: Yeah, this is an interesting one. Air-gapped networks are a big pet peeve of mine. An air-gapped network is essentially something that’s not connected to the internet in any fashion, and superficially, you’d say, “That sounds right, just disconnect everything.” Disconnect all the stuff from the internet, outbound connectivity, and I’m safe. Not really. There are plenty of examples of malware popping into air-gapped networks. If your listeners care to understand, one example of this is Stuxnet, and there are a couple of books on that, which are interesting reads. But yeah, air-gapped networks don’t work, so anytime I hear someone talk about them, I get angry.
But I think my biggest bone to pick, in general, is just the lack of consideration given to the operational effort and risk in enacting security policies and procedures. Security only cares about cyber risk and either doesn’t give any mind to it or is completely ignorant of the operational risk in mitigating cyber risk. There are a bunch of major initiatives right now like “get rid of all your passwords,” “just patch all your vulnerabilities,” “deny everything by default and only allow what’s absolutely necessary.” All of those things require an inordinate amount of effort, time, and risk to the business that security folks don’t have to think about. So that’s really the wrong information or the bad advice in cybersecurity – taking a generic paintbrush and saying, “Just do this thing in general,” without any understanding of the nuance and context of companies, the people in them, what the business actually does, and the decisions that go into it.
And, I see a lot of, generic advice on, if you just deploy a bunch of firewalls or you just get rid of VPN or you just do blah, it’s like there’s no context for what the hell is the business actually cares about? And so I would say just generic s***** cyber advice, just ignore it.
Samuel Brake Guia: Okay, that makes sense. And I have to say, while we’re speaking about this, it’s come to mind. I’m sure also curious to know what is some of the best cybersecurity advice you’ve heard, or maybe an easy way of saying what’s some of the best cybersecurity advice you could give?
Mike Starr: Really, it comes down to understanding what matters to the team, understanding the group, and it kind of sounds like this Kumbaya BS, but really it comes down to who’s on the team? Who are the stakeholders? And truly understanding what are the problems that you have? What are you solving for? What are the things you’re afraid of? And then building, let’s call it, a quote-unquote plan. It sounds boring, it sounds difficult. But really, the plan is like, do we have a bunch of branch offices that only have digital nomads or whatever? And just have laptops? Do we actually need a VPN? Do we actually need a firewall? Do we actually need printers?
Understanding what you need is the best advice that I can give – understanding, and this is not just cyber, it’s engineering in general – is understanding the problem you’re trying to solve for, truly understand it before telling people to just go do the thing.
Samuel Brake Guia: Okay, thank you for sharing that. I also have to say, I’ve checked out your website and I saw recently, the folks published an article on your blog titled, “Consider the Human Factor in Cyber Breaches.” Now based on this article and your own knowledge, what advice do you have for the listeners looking to stop cyber breaches and how can they address the human factor?
Mike Starr: Yeah, I won’t get on my, quote-unquote, “preventing cyber attacks” soapbox because it’s just unrealistic, especially given the current state of affairs in the cyber landscape. But the human factor part of your question, that’s damn interesting. The human factor is just realizing that security operations or infrastructure, whatever you want to call them, and everyone else that’s involved in all the other stakeholders, we’re on the same damn team. And don’t get me wrong, I’ve been guilty of this most of my career, where I’ve been a security weenie or an infrastructure weenie multiple times across multiple companies. But in each time, my perspective was, “Why don’t those assholes just do their job?” or “If only those jerks in security actually knew how to do anything but run an SS or a burp scan.” In those programs, we never got anything really done. And now there are a bunch of things that go into this, but when you realize just one of the major contributors to this mindset that’s a combat of mindset as opposed to a collaborative one, it’s just a lack of context. You can start to understand why you’re being asked, quote-unquote, “stupid questions” from security like, “Hey, the CD just came out. Are we affected?” or “Why can’t we just patch everything in the maintenance window tonight?” or what seems like indifference or unmotivated IT folks just pushing back on security with, “I’ll get to it when I get to it” or “You even have a ticket number?” The human factor is just exactly what it sounds like – just treat humans like humans, not roadblocks or obstacles that you need to bulldoze and get out of your way to get your stuff done.
Mike Starr: And really, I believe that there are two main influences on an organization that prevent collaboration and reward conflict. The first is pretty obvious, right? It’s just assholes in leadership and day-to-day operators being assholes. And we have a strong “no assholes” policy here. As a result, the team is hands down the best I’ve ever had the pleasure of working with. And there are no egos. We get things done, people help each other, and no one’s afraid to say, “I don’t know,” and we work to resolve things together. But people that are not aligned with looking at the community as a whole or the business as a whole, we’re in this together, that is one major source for this thing and it’s really hard to change human behaviors. I’ve staked my career on doing that and have been somewhat successful in doing so, and we’ll continue to push that envelope forward.
Mike Starr: But the second one is a little less obvious and more difficult to address, and it’s that vendors perpetuate this false dichotomy, especially between IT and the security teams. The culture, in general, in an enterprise is like you’re either on the security team or you’re not, and it’s just b*******. They perpetuate this false dichotomy either purposefully or just in ignorance between teams because it’s just easier to sell into a single business unit. So if you look at all the major IT software on the market today, it only solves for IT stuff. And if you look at the security tools, they only solve for security stuff. But when you realize that security cares about cyber risk and IT cares about operational risk, and just only having one is worse than useless, it’s a main source of frustration between these two teams, and the adversaries clearly have a leg up. So if you can start to bridge this gap between these two teams and the tools they use, to start having questions instead of just go patch that stuff, like, “Hey, y’all, this new vulnerability is available or actively being exploited. They’re targeting financial institutions, and it seems on Twitterverse or Reddit or whatever else this patch hasn’t really broken anything. Can we patch more aggressively?” You start to have these kinds of conversations that start from a place of collaboration as opposed to competitiveness. And that’s really what the human factor is, and it sounds like Kumbaya and blah blah, but you hear a lot of lip service around cybersecurity is a people problem first, and it’s only lip service. What group of tools actually focuses on truly fundamentally human bottlenecks or human conditions first? They don’t really exist in the market.
Samuel Brake Guia: I’m not going to lie, I did very much love, and I’m still smiling as I laughed when you were saying about the “No A**holes” policy. I can just imagine going to your careers page and just seeing that in big capital letters “A**holes Need Not Apply.” That’s brilliant.
Mike Starr: That will definitely be a headline when we have a careers page on Trackd. It will be there, I guarantee you that.
Samuel Brake Guia: Fantastic. I love that. And obviously, like you mentioned there, when your careers page comes up, that sounds like it’s going to be something that’s going to be in the future. I mean, what else is on the horizon for you folks at Trackd?
Mike Starr: Yeah, our goal, at least for the first half of this year, is to expand our network and install base. We’ve had our private beta open since March, and we’ve got a bunch of folks on the platform, from multi-hundred billion dollar market cap companies to really tiny law firms. We’re really just trying to focus on eliminating vulnerabilities. So in the enterprise, we’re building out these tools and features that help people reason about patches and vulnerability management in a way that aligns with their corporate risk strategy. We want to give them metrics that actually matter and help them quantify their fear of uncertainty. And so that’s our big focus – getting people to realize that patching is generally safe. And then building these kind of guardrails to allow them to roll out patches in a way that aligns with their corporate risk strategy. The patch’s known impact, but most importantly, the operator’s life – if they patch tonight, are they going to miss a Tinder date? Are they going to miss their daughter’s recital, or will they patch too fast at the urging of an existing executive only to come back the next day and be yelled at for causing downtime by that same a******?”
Samuel Brake Guia: That’s very considerate. And I am really excited to see how you folks develop. And if people are listening to this and they want to keep up with the work that you are doing, what’s the best way for them to do that, Mike?
Mike Starr: Yeah, head over to Trackd.com. There’s a form where you can ask me anything, or you can just reach out to me on LinkedIn or at my email: [email protected]. Happy to chat!