515. Nathan Reller (Ginger Cybersecurity)

Email: bidemiologunde@gmail.com

In this episode, host Bidemi Ologunde speaks with Nathan Reller, CEO of Ginger Cybersecurity, about his path into cybersecurity, the lessons he carried from research and engineering into entrepreneurship, and why simplifying infrastructure may be one of the most practical ways to reduce cyber risk. What happens when an operating system is designed with fewer than 20 files? How does removing login credentials change the security model? And why do complexity, compliance, and communication so often become hidden obstacles for security teams? Nathan also discusses Ginger OS, the company's approach to explainable security, and what it takes to build trust with technical and non-technical customers alike.

Transcript

SPEAKER_00 0:16

So thank you for joining me once again on another episode of the Beat Picture podcast. I have a special guest who is a cybersecurity professional and is also local here in the Tampa Bay area. And we met a while back at a conference. And then we also we we've met at a few conferences. And I'll just let him introduce himself. Over to you.

SPEAKER_02 0:41

Okay. Hi, I'm I'm Nate Reller. So yeah, I'm into cybersecurity. So I have a company called Ginger Cybersecurity. That's where I do most of my work now. So we we created a new Linux-based operating system that has less than 20 files and all of user space built in Rust. And by having that small number of files, that's how we uh improve cybersecurity to make that job easier. Um and prior to that, I was a cybersecurity researcher for I don't know how many years, over 15 years. I studied areas in um measurement and attestation, trusted computing, cloud security, and uh security orchestration, automation and response.

SPEAKER_00 1:31

Nice, nice. So before cybersecurity became your profession, what first pulled you towards systems, engineering, and problem solving?

SPEAKER_02 1:43

So I've always liked problem solving. I liked building things. So as a as a kid, um you know, coming up, I I played soccer, and like one of my favorite projects was uh I grew up like in a farm area. So like just building uh like the side of my barn, like boarding it up so I could kick a soccer ball against it, building little rebound walls and stuff like that was always fun. So I kind of got that love for building things back then. Um and then when I got to college, I didn't really know what I wanted to do. Um, and I just like I'm just gonna try engineering and business, and I suck with engineering. I like that more.

SPEAKER_00 2:24

Nice, nice. So um, in your earlier technical work, um what when did you first realize that complexity itself can be a security risk?

SPEAKER_02 2:37

I didn't realize that until late in my career. Like for me, I just you know, I was learning so much. Like when I started in cybersecurity, I didn't even know what cybersecurity was. Like, so I've come a long way uh from that as the field develops, and I didn't realize how much it uh the complexity affected security until I tried to apply it myself. I just, you know, I was focused on my little research areas, hyper focused on that on that niche. And then when I was like, man, I really want to deploy something on my own, like a a piece of software that I wrote, that's when I really became overwhelmed and I started to to look at like what are other businesses doing? And that's where I kind of realized, okay, I'm not alone here. Other people are feeling this uh anxiousness when they're deploying things. I mean, that's I that's why we have expressions like it's not if but when. It's it's it's almost like you're resigned to this mindset. It's just like it's gonna happen, you know, just don't worry about it. That's when it really stuck for me when I when I had to deploy my own stuff.

SPEAKER_00 3:49

Nice, nice. And it's something I can definitely also relate to because as a cybersecurity professional, we deal with systems of systems, and the closest analogy I like to use that everybody can grasp is the human body. So let's say, for example, you have a headache. Well, that means something is wrong in your body. A headache is one of those things that could be caused by 20,000 things. If you are dehydrated, you could have a headache. If your teeth, something is going on with your teeth and your gums, that could cause a headache. If you live in Florida like we do, and it's allergy season and your sinuses are all messed up, you could have a headache. If you sit in a bad posture for too long, then you have a headache. So now we have a case where a network of computers, the more complex it is, the more likely something is going to go wrong. So when we now talk of security of a network, which is a subset of that network, well, a complex network is more likely to have security problems than a less complex network. So my roundabout way of presenting my next question is basically to then ask you so when ginger was still just an idea, what was that first problem that you wanted to solve that you felt like the industry wasn't really focused on or paying attention to or just overlooking?

SPEAKER_02 5:23

Yeah. So for me, that was trusted computing. So I I was into um trusted computing, which if you're not familiar with, is like basically how do you uh appraise and attest to the health of a computing system. And you know, you have things on your motherboard, like the the trusted platform module, which is um it's kind of like a smart card that's soldered onto the motherboard, and it will take hashes and measurements of different components of the system as it started. So the theory is that as the system boots up, you know, you measure the bootloader, uh, the bootloader measures the kernel, the kernel then measures the init process, and then you're you have this chain of trust that you uh for the system. And it sounds really great in theory, but then when you are like, okay, let's get past the kernel, it's like, well, we don't we don't really know what to expect there. Like things get complex very quickly. You know, you have init, and then a knit just kicks off all kinds of uh stuff there. So that for me was um when I was just like, I want to actually apply this concept to measure the integrity of the whole system, and for me, the only way I could think of to do that was to make a less complex system. Yeah.

SPEAKER_00 6:52

Right, right, right. And you've also been a vocal proponent of not just trusted computing, um, measurement and attestation, SOAR, cloud security. Which of these niche areas have most changed how you think about cyber risk?

SPEAKER_02 7:15

I would say how we think about cyber risk, I would say SOAR because for me, that's where I really saw the the impact of something simple, right? So prior to security orchestration and this automated response, when you worked in a in a in the security operations center, you know, the guys who are looking for the flashing red lights and responding to the alerts from uh antivirus and stuff like that, it was just a very repetitive work, and seeing how the automation helps cut down on that risk was really eye-opening for me. It was like, oh man, why didn't we do this earlier? Like it seems seems like a good place to put that there.

SPEAKER_00 8:08

Huh. So your company's public mission statement, let me just put it that way.

SPEAKER_01 8:15

Yeah.

SPEAKER_00 8:16

Is it basically started by asking, okay, what's what would happen if an operating system had fewer than 20 files? So why was reduction as a concept the right starting point for you?

SPEAKER_02 8:31

Yeah, so I I'll just take it back to the example that that I had earlier. You know, you asked me like, what was that kind of idea that I was trying to get after? And it was just, you know, I it was the only way I could figure out how to apply these concepts was to reduce the complexity. Um, you know, application whitelisting or allow listing is is a great example, right? It's this it's a very simple concept. I don't want malware to run on my system to only run the set of approved binaries on my system. But when you try to apply that on Windows system or Mac, and I don't want to pick on those systems because they're general purpose computing, but it's very difficult to manage that. Like if for anyone who's ever sat on a lot on uh in a security operation center, um, you know that that is very difficult. Constantly, yep, new binaries updated all the time.

SPEAKER_00 9:29

Yep, yep, yep, yep. So um another side of you that a lot of people may not necessarily know about is you publish um security research, um, sticks and taxi related Oasis work, um, OpenStack, and so on. How did standards work and cloud research shape your view of real security versus checkbox security?

SPEAKER_02 9:54

How did that shape real security versus checkbox? Well, uh that's a tough question there.

SPEAKER_01 10:05

Sorry.

SPEAKER_02 10:06

Yeah. Because I did is uh that one's a little bit hard for me to answer because I don't feel like that work. It was standards based. Typically, when I think of the checkbox security, I'm thinking of like compliance with some sort of regulatory standard. Whereas like Sticks and Taxi was how can we how can we uh get this group of different organizations with different priorities to come together to create a working solution? So I think it's a little bit different um with with that type of standard there.

SPEAKER_00 10:46

Right, right. Okay, okay. So um another thing your your organization is focused on, to put it that way, is of course we've mentioned this, simplifying security reviews and making controls easier to prove and explain. So, at what point did you realize that compliance friction was actually a product design problem?

SPEAKER_02 11:12

Yeah, so yeah, the the friction is is definitely real. Um it's very difficult to go through those compliance standards. One for me just to interpret what they're what the core of the matter is, and then two to be able to answer them sufficiently. Um, you know, like one of them is uh I think from CMNC, you know, what is uh you have to give a like a list of all the approved software that's allowed to run on a system.

unknown 11:47

Right.

SPEAKER_02 11:47

So applicate that's basically another way to say application whitelisting or application allow listing. And to answer that question on a normal system, there's hundreds of binaries that are on that system. Um so yeah, that friction is definitely real because you're like, how do I how can I realistically answer this? I'm not gonna go through hundreds of binaries and go, uh, you know, create this table, right? You there's kind of this generalization as that's part of that process. And I think that's uh that's a lot of the friction there is like, okay, it's a little bit unrealistic what you're asking. So what's the real answer that I'm supposed to give you?

SPEAKER_00 12:30

I mean, so for me, product design in IT security, cybersecurity, it's inherently a function of going through checkboxes. Because now you have, okay, maybe you're building something for a client, or you're an MSSP, a managed security service provider. Your client says they need whatever amount of security on whatever amount of machines and boxes, and we need this to be internet facing, and we need this server to be just behind a firewall and be air gapped and so on. And then you come back to them with a bunch of product design specifications that meet their needs. Embedded in those design specifications are inherent security risks that they wouldn't know until they get DDoSed by a Ukrainian IP at 200 200 gigabytes per second on a Saturday evening. And then where do we go from there? So it's it's one of these questions that I struggle to even answer myself, and I'm just like, you know what? Everybody's doing their best, and your security is as good as what your CTO can come up with, or maybe I'm just thinking about it upside down, who knows?

SPEAKER_02 13:49

No, I would agree with that. I would also say that like you know, hopefully, who when you're designing that software, you you're letting your customer know that there are different options out there, right? So, like um if you need uh like one example that I have is like sometimes I'll use uh a SQLite database, which means there's just one server instance that sits right in front of it. And for some deployments, uh I'll say, hey, you know, there's the risk, like if the server goes down, like we're down for down for a while. Whereas you could say, well, we could try high availability, like so. If we get DDoS on this, well, we if we're replicate that database in the different regions, well, we can just pop up and set it in a different region to get that. But there's a cost, there's a trade-off uh that that that needs to be brought up. Right, right.

SPEAKER_00 14:45

So um on the Ginger OS, um, there are no login credentials. Um basically no one can log in, even with physical access. So was that decision more of a philosophical stance or a technical necessity?

SPEAKER_02 15:00

Uh it was I would say it's more of a a happy accident, if you're you know, it was kind of like I I knew I I was a big fan of immutable infrastructure. Um so I didn't want people to be able to log in uh and change things. So, but I didn't I didn't realize that from the beginning. It was more of like, hey, I want the system to boot up and I want it to run, you know, whatever web app I was developing. And it kind of it wasn't until after I was I designed it and I was like, okay, this is how it's gonna start, it'll boot up, it'll run this, and I was like, oh my goodness, I don't I don't need the concept of users. Like basically, I'm just gonna run these things with uh uh different user IDs to keep them isolated, but it was like one of those, oh my goodness, this is a really great security property I have here because I don't have to manage passwords, I don't have to you know to worry about any of that. So I would say, yeah, that was that was a nice side effect.

SPEAKER_00 16:08

Nice, nice. And there is also one thing you prioritize. Um Jinja verifies authorized executable code every minute. How do you explain that benefit to a non-technical buyer without oversimplifying it?

SPEAKER_02 16:30

I'll explain it. I don't know that they always get it, so I'm always I'm still working on that. So I'll just let you know that. But yeah, I mean, I I just try to explain it and say, like, hey, every piece of code that's running on that system, uh, except for the kernel, which I know that they don't get that, but that's like your monitoring agent, that's your root of trust there, essentially. I just say we're going through all those binaries, and in particular the web app that you're developing, and we're scanning all the executable code of it. So if an attacker comes in and they try to modify a bit or add any new code, like we'll detect that. And I think I think they kind of get it at a high level. I mean, they definitely don't know what I'm talking about when I say kernel and user space, but when you just explain it, yeah, like we're checking the code. So if there's any new code that goes on that system, like we'll let you know.

SPEAKER_00 17:18

Nice, nice. And another side of you that a lot of people may not necessarily know is that you teach Rust in community settings. So has teaching made you a better builder or a better communicator?

SPEAKER_02 17:33

Both. Yeah. So I would say, you know, when you go through, it's one thing to go and build something, it's another to be good enough at it that you feel comfortable explaining it. And then like it's really another level when you can explain it easily and quickly so that way you can respond to questions. So it really challenges me, my concepts. Because I'll uh you know, before I give a talk or something, like um, I like to anticipate questions and I'll and I'll answer myself out loud. I'll just feel like, man, that was a that was a terrible answer. I gotta I gotta refresh myself here. So yeah, it definitely challenges me. It's it's it's very beneficial, both for learning how to to write the code as well as explain it.

SPEAKER_00 18:20

Nice, nice. Um, another part of um the ginger organization is Jinja VM workflow and some sample applications for Rust, um Apache 2 and Node.js. So early on, was the bigger goal developer adoption, proof of versatility, or even credibility with security bias?

SPEAKER_02 18:48

Uh I'm not sure I'm I'm tracking the question.

SPEAKER_00 18:52

So your your I guess documentation show you have this a Ginger VM workflow. I'm guessing that speaks to developers.

SPEAKER_01 19:03

Yep.

SPEAKER_00 19:03

And then there are yeah, and then there are sample applications for Rust and Apache and Node.js. So what did you have a bigger goal of focusing more to developers or showing credibility with people that buy security products?

SPEAKER_02 19:20

So my original thought process was that this would resonate with developers first, and then it would get sold as cybersecurity. I found that to be the opposite. Developers are like uh they don't like change, and they don't I found them to be uh of the mindset like our ops team will handle cybersecurity, so unless they tell me to change, I'm just gonna keep doing what I'm doing. Whereas when I go to the cybersecurity community, they're like, I like that. That's that's clever. Like, so I I find two different responses, like the cybersecurity, I was surprised that they were like, Man, that's a great concept. I I can see how that would really uh make life easier for me. Um, and then the developer, it's not much different, the workflow from what they normally do, but they're just they seem more uh there's a lot more inertia there.

SPEAKER_00 20:22

Nice, nice. So, one question I like asking founders is in terms of their identity and that inevitable shift in identity. So initially you are building, you're focused on building, and then slowly but surely you become a public-facing member of your own organization because the bigger you grow, someone has to still, you know, evangelize what you're trying to do. So, how has your identity shifted from builder to operator to public spokesperson?

SPEAKER_02 20:58

Yeah, so I would tell you that like three to four years ago, I would have I would have turned this down because I'm very introverted. I would say, no way, I don't like to do that. Even though I've given some talks in the past prior to that, it made me very anxious. Um But I what I found going through this process, this is an idea that I am very passionate about. I I believe that this will change cybersecurity quite quite drastically in favor of cyber defenders. And so I think it's because of how into this I am, how how passionate I am about it. Like being that public facing figure, it doesn't bother me as much. Um, so I'm more comfortable uh you know coming on podcasts or discussing this at conferences or whatever it might be. Um but yeah, it is it definitely um is different, and I have to spend a lot of time practicing to get more comfortable with that. Um So my day is different. I don't get to code as much as I would like. Um, but it's you know, it's nice to come on here and and have these interactions uh with you and others in the community just to learn different things. It's been very fun.

SPEAKER_01 22:13

Nice, nice, nice. Wow.

SPEAKER_00 22:16

I feel like I get similar answers, whether I'm speaking to people at a conference or I'm speaking on the podcast like this. It's more of okay, almost everyone I know in cybersecurity starts off as an introvert. I am an introvert. I may come across as an extrovert. If you meet me at a conference, you'll be like, oh, this guy's an No. I am an introvert. Even on this podcast, the first two minutes, I'm nervous. It's my podcast, but I'm nervous for like the first two minutes, and then I start to, you know, slowly get into it. But it's one of those things where at the at the fundamental level, we are all marketers of ourselves. So you meet someone, you're trying to develop a relationship. It's your partner, your friend, your co-worker, your co-founder. You are marketing yourself to that person. You are the CEO of a startup, or you are the CEO of Google and Facebook and Apple, you are marketing your company to all these other people in different settings. Maybe it's in an elevator, in a hotel conference setup, or it's on a podcast like this, or it's on the stage and you are the keynote speaker of a conference. We are all basically marketing ideas and marketing our personalities and so on. So it's one question I always like to ask. So that's why I asked the question. So um, to kind of start wrapping up here, I have two more questions for you. Um, for anyone coming from a research background, an academic background, or just deep engineering background, and they're thinking about starting a company, what part of that transition is emotionally harder than it looks?

SPEAKER_02 24:02

For me, where where I am, I would say the emotional part kicks in when you when you when the money runs tight. So that's you know, you're excited at the beginning, you're building, you're doing this, all this fun work, and then you're like, I gotta, I gotta, I gotta start selling this, right? Like, I got family, I got mouths to feed. That is the part where it it becomes the most stressful. And that was I didn't think I didn't think it was B as bad as it is. Um, I guess most of the time I'm pretty flexible, like I was kind of prepared for it, but then it's um no, it's been pretty it get it gets rough at times. And then the failures, you know, like because you know, when I first started in sales, you you you get rejected, right? Because you're you're you're bad at it. Like I tell my kids all the time, starting something new, you're gonna you're gonna be bad at it. Like it's just that's just the way it is. And and that was the same for me going through the sales process. You're like, man, uh, you know, you can leave a meeting, you're just like, I totally blew that. Like, I did not communicate my message. Like, like you talk about user space executables. I was like, man, I didn't I was trying to go too technical on them, totally lost them. You know, you just have that feeling. Um so I think that that part is for me where I got the most emotional. Um, you know, trying to do the sales, out of my comfort zone already, being an introvert, and then trying to make money, make ends meet. Uh that that was rough. Um, you just keep pushing through and it'll all work out.

SPEAKER_00 25:47

Thank thanks for sharing that. And it's a belief I have is the more you do something, the more you know how to do it. Especially if it's something you're passionate about, if it's something you believe in, and of course you trust all the good advice you get from the people around you, and you know, eventually things work out. So yeah. So final question. Um, looking ahead, how do you want ginger cybersecurity to be judged in the next few years? Is it in terms of technical elegance or fewer incidents or customer results or something else?

SPEAKER_02 26:27

Yeah, so I, you know, uh we obviously want um fewer incidents, like that's what we want. Uh the some key metrics that we're always I'm always interested in is that is the customer experience, right? I want to get my customers to adopt this technology and go through something like a compliance check and come back to me and say, hey, we've done this in the past for uh these servers. Now we tried it with with Ginger OS on a subset, and this works great. Like we saw this dramatic decrease in time, and and more importantly, a dramatic increase in confidence that we can defend ourselves from cyber attacks. Like that confidence is a really big thing that that we want. Um, like you said, we don't want people to just have a checkbox or think they have like a magic tool that's gonna stop everything. We want them to understand the system, have the confidence to implement the cybersecurity and know what to do and how to respond when they do get an alert, right? Because whatever software they wrote is gonna have a bug in it, and people are gonna try to exploit it. And if we can make them prepared um and ready to handle that as we protect them, then then that's what we want.

SPEAKER_00 27:46

Nice, nice. This has been a really um fun and insightful conversation. And thank you once again for um agreeing to this at relatively short notice because this whole thing started at was it last month at Cyber Bay. Yep. And then here we are um on the on the podcast. So thank you once again, and I hope to stay in touch with you so I can witness all your good successes in the near future.

SPEAKER_02 28:13

Thank you so much, and I really appreciate you having me on the podcast. It's always fun to chat with you. We always have good conversations. So now everyone in here.

SPEAKER_00 28:22

Thank you so much. Talk to you soon.

SPEAKER_02 28:24

All right, thank you.