Embracing Curiosity: A Journey into IT, Security, and Continuous Learning

How's it going, sige? It's really good to finally have you on. I think this thing has been scheduled, rescheduled, like so many times. It's definitely mostly my fault, so I apologize for that, for sure.

No problem. No, I think I might have canceled a few myself as well. I'll get it.

So, sige, i always start people off with having you tell their background right of how you got into IT, how you got into security, what kind of made you go down this path. And the reason why I do that is because there's a lot of people that listen to my podcast that are looking again at security, that are looking to get into IT, and they don't know if it's possible for them, if it's right for them. So I feel like hearing a different background, which I've done over 100 episodes. I've never heard the same background. But hearing that different background lets my audience know that they have a chance at actually making this work for them.

Yeah, no, i love that And I think it is interesting to hear these different stories, especially the non-conventional ones, and they come up much more than I guess people would expect. Mine is no different. I started just tinkering with computers when I was a teenager And I don't know what it was. I mean, we sort of enjoyed building things with my hands Legos, building projects, whatever. Just sort of the high of sort of creating something from nothing was interesting. And then I got into probably it was video games that got me into computers. But one of the things that was interesting was my first. I had some older machines, but when I was like 13, 14, i actually got like an Intel-based PC And it actually had a pretty good warranty from the manufacturer which was compact.

And as I go about my business playing different games, you run into sort of issues and slowness and, okay, you got to upgrade my memory, you got to upgrade this and try to do it myself And I burned out the motherboard a few times or broke this or broke that, and I was lucky that you know thing had a great warranty And every time that would happen they'd send me like a replacement or a new part And it was great because it afforded me the ability to kind of learn based on my mistakes and teach myself how to fix these things or how they work. And that was that's the way that I learn kind of need to get my hands on it and just sort of get into it instead of just being sort of dictated. That's how I got into it And then, you know, just sort of go down the rabbit hole, enjoy sort of getting into programming, sort of getting into the chat rooms with different people, heard about this thing called Linux, you know, installed it, you know based on like 40 floppy disks or whatever, and at that point it was just cool making things work. And you know, there was no, there was no Google then, and there was, you know, not even in classes about this stuff. It was all very bleeding edge, and so I think one of the big takeaways was you had to figure things out on your own, and if it meant sifting through resource code and making some changes and re-compiling, like you know, that was all you really had.

And eventually that you know eventually I went to college for computer science but I got a job at a local ISP company running their BSD and Linux servers, and that was like the late 90s And that's when websites started getting popular And so I was mostly running just hosting websites on Apache and so on. And then I met another person working there who would become my business partner. He quit and said he wanted to start his own hosting company And eventually he convinced me to go join him and then kind of rest with history. We're at the right place, right time, but no rulebook learning as you go, say yes to everything, figure out how to get it done after you know. Just a lot of battles.

Yeah, that's, that's really interesting how you put it. You know, say yes to everything and figure it out later. It's, you know, i can't remember where I heard that from, but that really put kind of like everything in the perspective for me. You know, like you're not going to know everything right off the bat, but you saying yes opens you up to getting that experience for you to learn it. So then you know, you'll know it forever. Then at that point, is that kind of your mentality too with it. Was it scary for you at first, just jumping into things and not, you know, knowing it? Was it exciting? What was your mentality with it? It was exciting.

I mean I would say it's a little scary. I mean I think it's exciting because it's a little scary, right. And for us, you know we had, we started off by hosting our friends websites and we were at, you know, right, right place, right time, not many sort of options on the internet. We were one of the first ones, and so we had a lot of random customers that would come in and they all have different requirements. You know, different industries, different applications, different use cases, and what's great about that is they're all coming at you with different problems to be solved And so you don't really have to think much. You know either you can solve the problem or their business is going to go elsewhere, and you know so.

I remember you know we were hosting all small websites and one of our customers, the Groo and Groo, and they outgrew a server and you know we had to get a load balancer, which was a big deal back then And never. You know that was exciting And I never installed one before and I was up all night, you know whatever. And Dave sent her a few days and got it working, and so as soon as his business scaled and grew, you know, so did we And I remember afterwards he said you know he's like I don't know if you've ever done one of those before, but either way, like good job, you know, like you kind of kind of knew, but like I don't think he cared because he was kind of in the same boat. I think that's so like if you have customers or you have people that are asking you to do things, what's great is they're not asking you or not telling you to go and learn a certain technology. They're giving you a goal, something to achieve, and you just have to figure out what that looks like along the way and what you need to learn and what you need to figure out, and I think that's the right way to do it.

I think today there's a lot of people that are trying to get into these technologies And in our industry there's way too much sort of shiny objects and drum. You know everyone's hyper focused on you know the newest coding language, and it's all about sort of stacking your resume and listing out all the technologies you know. So there's kind of like this, this undertone of pressure to have to learn all these technologies. I think that if people like are presented with a goal, go and build an application that does x, y or z or feeds your dog automatically. Whatever. You're going to be forced to find the right tools and languages and platforms to get it done, and that's how you'll learn them right. Anytime you kind of sit down, you say, all right, i'm going to teach myself x today. It's like it's no fun, you know.

Yeah, that's a really good point. You know, i was talking to someone this was a few years ago, at this point where he had just gotten out of college and he was trying to get a job as a developer and he couldn't get a job as a developer. He got his bachelor's in computer science and whatnot And he knew the different, you know, languages that he had to learn, that he needed to know for these jobs that he was applying for, and he didn't really get it. You know, and I recommended to him that he actually do his own projects, right, like he started just thinking of different applications, different things that he would find useful and maybe someone else would as well, and start posting them on GitHub, you know, and start kind of just learning it from that angle.

You know, because I think people forget that just because you've got a degree doesn't mean that you know, you have demonstrable knowledge, it doesn't mean that you can put all that together into an application and build a whole stack around it right and have it all talk to each other and actually provide a service. And you know, i thought that he was actually going to do it but lo and behold, he didn't actually do it and he's still not even in IT. He's like working at a baker shop or something like that, and there's nothing wrong with that right. But when you tell me that your goal is to get an IT, to be a developer for a company, and then you know, four or five years later you're still in the same spot, it's like all right, well, what'd you do? Like obviously nothing, or not the right things you know.

Yeah, i agree, i think that there's, you know, a good way to kind of.

How's it going, sige? It's really good to finally have you on. I think this thing has been scheduled, rescheduled, like so many times. It's definitely mostly my fault, so I apologize for that, for sure.

No problem. No, I think I might have canceled a few myself as well. I'll get it.

So, sige, i always start people off with having you tell their background right of how you got into IT, how you got into security, what kind of made you go down this path. And the reason why I do that is because there's a lot of people that listen to my podcast that are looking again at security, that are looking to get into IT, and they don't know if it's possible for them, if it's right for them. So I feel like hearing a different background, which I've done over 100 episodes. I've never heard the same background. But hearing that different background lets my audience know that they have a chance at actually making this work for them.

Yeah, no, i love that And I think it is interesting to hear these different stories, especially the non-conventional ones, and they come up much more than I guess people would expect. Mine is no different. I started just tinkering with computers when I was a teenager And I don't know what it was. I mean, we sort of enjoyed building things with my hands Legos, building projects, whatever. Just sort of the high of sort of creating something from nothing was interesting. And then I got into probably it was video games that got me into computers. But one of the things that was interesting was my first. I had some older machines, but when I was like 13, 14, i actually got like an Intel-based PC And it actually had a pretty good warranty from the manufacturer which was compact.

And as I go about my business playing different games, you run into sort of issues and slowness and, okay, you got to upgrade my memory, you got to upgrade this and try to do it myself And I burned out the motherboard a few times or broke this or broke that, and I was lucky that you know thing had a great warranty And every time that would happen they'd send me like a replacement or a new part And it was great because it afforded me the ability to kind of learn based on my mistakes and teach myself how to fix these things or how they work. And that was that's the way that I learn kind of need to get my hands on it and just sort of get into it instead of just being sort of dictated. That's how I got into it And then, you know, just sort of go down the rabbit hole, enjoy sort of getting into programming, sort of getting into the chat rooms with different people, heard about this thing called Linux, you know, installed it, you know based on like 40 floppy disks or whatever, and at that point it was just cool making things work. And you know, there was no, there was no Google then, and there was, you know, not even in classes about this stuff. It was all very bleeding edge, and so I think one of the big takeaways was you had to figure things out on your own, and if it meant sifting through resource code and making some changes and re-compiling, like you know, that was all you really had.

And eventually that you know eventually I went to college for computer science but I got a job at a local ISP company running their BSD and Linux servers, and that was like the late 90s And that's when websites started getting popular And so I was mostly running just hosting websites on Apache and so on. And then I met another person working there who would become my business partner. He quit and said he wanted to start his own hosting company And eventually he convinced me to go join him and then kind of rest with history. We're at the right place, right time, but no rulebook learning as you go, say yes to everything, figure out how to get it done after you know. Just a lot of battles.

Yeah, that's, that's really interesting how you put it. You know, say yes to everything and figure it out later. It's, you know, i can't remember where I heard that from, but that really put kind of like everything in the perspective for me. You know, like you're not going to know everything right off the bat, but you saying yes opens you up to getting that experience for you to learn it. So then you know, you'll know it forever. Then at that point, is that kind of your mentality too with it. Was it scary for you at first, just jumping into things and not, you know, knowing it? Was it exciting? What was your mentality with it? It was exciting.

I mean I would say it's a little scary. I mean I think it's exciting because it's a little scary, right. And for us, you know we had, we started off by hosting our friends websites and we were at, you know, right, right place, right time, not many sort of options on the internet. We were one of the first ones, and so we had a lot of random customers that would come in and they all have different requirements. You know, different industries, different applications, different use cases, and what's great about that is they're all coming at you with different problems to be solved And so you don't really have to think much. You know either you can solve the problem or their business is going to go elsewhere, and you know so.

I remember you know we were hosting all small websites and one of our customers, the Groo and Groo, and they outgrew a server and you know we had to get a load balancer, which was a big deal back then And never. You know that was exciting And I never installed one before and I was up all night, you know whatever. And Dave sent her a few days and got it working, and so as soon as his business scaled and grew, you know, so did we And I remember afterwards he said you know he's like I don't know if you've ever done one of those before, but either way, like good job, you know, like you kind of kind of knew, but like I don't think he cared because he was kind of in the same boat. I think that's so like if you have customers or you have people that are asking you to do things, what's great is they're not asking you or not telling you to go and learn a certain technology. They're giving you a goal, something to achieve, and you just have to figure out what that looks like along the way and what you need to learn and what you need to figure out, and I think that's the right way to do it.

I think today there's a lot of people that are trying to get into these technologies And in our industry there's way too much sort of shiny objects and drum. You know everyone's hyper focused on you know the newest coding language, and it's all about sort of stacking your resume and listing out all the technologies you know. So there's kind of like this, this undertone of pressure to have to learn all these technologies. I think that if people like are presented with a goal, go and build an application that does x, y or z or feeds your dog automatically. Whatever. You're going to be forced to find the right tools and languages and platforms to get it done, and that's how you'll learn them right. Anytime you kind of sit down, you say, all right, i'm going to teach myself x today. It's like it's no fun, you know.

Yeah, that's a really good point. You know, i was talking to someone this was a few years ago, at this point where he had just gotten out of college and he was trying to get a job as a developer and he couldn't get a job as a developer. He got his bachelor's in computer science and whatnot And he knew the different, you know, languages that he had to learn, that he needed to know for these jobs that he was applying for, and he didn't really get it. You know, and I recommended to him that he actually do his own projects, right, like he started just thinking of different applications, different things that he would find useful and maybe someone else would as well, and start posting them on GitHub, you know, and start kind of just learning it from that angle.

You know, because I think people forget that just because you've got a degree doesn't mean that you know, you have demonstrable knowledge, it doesn't mean that you can put all that together into an application and build a whole stack around it right and have it all talk to each other and actually provide a service. And you know, i thought that he was actually going to do it but lo and behold, he didn't actually do it and he's still not even in IT. He's like working at a baker shop or something like that, and there's nothing wrong with that right. But when you tell me that your goal is to get an IT, to be a developer for a company, and then you know, four or five years later you're still in the same spot, it's like all right, well, what'd you do? Like obviously nothing, or not the right things you know.

Yeah, i agree. I think that there's, you know, a good way to kind of get exposed to is go on a freelance or another one of these consulting websites and do people's projects for free or super low cost, because they're again, they're challenging you, They're putting a goal in front of you and it's going to force you into learning something. And when I've interviewed people over the years, yes, i look at the education, but I'm way more interested in what have you done. Tell me about the coolest thing that you've built. Flex your geek muscle and tell me how low level you've gotten or what you're most proud of. Maybe it's a project or maybe just some crazy issue that you have to have to troubleshoot that sticks out. But show me how deep you can get into the weeds, and there are ways to do that. Like I said, go do a free project Back when I went to school too.

I kind of agree with you. I think there's much more specialized education these days, but I think up until recently, the education that you would get was sort of like a taste of all these different either coding languages or aspects of IT, and they kind of don't tell you. It's like hey, we're going to give you a class introducing you to all these different layers, but you should probably go home and dive deep into one, because who wants to hire a generalist at a college? You need to take that and we're giving you a sample. You figure out what you like, what you gravitate towards, and if you really like it, you're probably going to end up spending some of your free time doing it and build some projects And then when you go in for resume I think for an interview then you're really sort of marketable.

Yeah, i found when I was trying to get into security myself, that was one of the biggest hurdles, or even one of the biggest questions that was asked to me. The most even was what do you do in your free time? Like that's great that you know all this information and whatnot, but what do you do with it in your free time? Are you a nine to five security person, or are you a 24 by seven security person that is going to be researching different vulnerabilities in zero days and whatnot like in your off time? And I always felt that that was one of the things that kind of, i guess, separated me from the pack. That I didn't think of it at the time like that, but later on, talking to my hiring managers, they definitely took it like that, like even this podcast.

It's like an example of me trying to not only meet new people, learn new things, but also help the security community in a way that I wasn't doing it before. It's better when you do the extra work, when you do that little bit extra, because that's what's going to separate you apart from everyone else, at least in my opinion And you know you sounds like you agree as well That's what you're looking for as an employer. You're looking for the people that you know. I actually love what they're doing.

Yeah, absolutely. You know what that reminds me of is. You know, over the years you know I would have to text working for me and they would be dealing with customer issues And you know, oftentimes they would. They would troubleshoot something or try to fix it And at some point they sort of reach that threshold and kind of give it to me and say, hey, i'm stuck, i don't know what to do, i can't get this working, and that's all right. You know, send me the information.

And now it was on my plate And either either you know I figured it out or we lost the customer. They went elsewhere, and you know that's really good motivation, you know, and sometimes it's not convenient. I remember, you know weekends of just you know Windows Blue screen of death And like, either I figure this out or or you know losing revenue. And so it was great for me because it taught me. It taught me some really good troubleshooting skills, which is, i think, a skill that people don't focus enough on. But also it was good for me, it was good for the customer in most cases, but it was not good for the tech that kind of let go, because they're they're losing an opportunity, they're missing an opportunity.

And you know, one of the things that I think people need to realize is you know to what extent is your work environment playground. You know, for you to experiment and learn and teach yourself new things. Like if your, your boss, is giving you, you know, leeway or more time to troubleshoot or work on something to figure it out, you know and they're okay with that, then you should not be giving up or throwing up your hands. You know that's a gift And so when people have worked for us over the years, you know it took me a long time to kind of realize that that's an asset. You know we're we're, you know, working with us in similar environments, we're hosting different workloads for customers in different verticals and industries and they're using different IT stacks and applications.

That's a playground. You're getting exposed to all these different things. You're not pigeonholed. You're, you're, you're, you're. Maybe you're solving the same challenges often, but there's the same challenges in different environments, so it's always different And in fact, i've had a lot of people that quit and went to work elsewhere. You know big name companies and then they come back like, hey, you have any side projects for me? You know I'm kind of like getting bored. So I think people need to look at that too. Like, okay, you know, look at the comp, you know, look at your salary and all that, but to what extent do I have an opportunity to learn here?

Yeah, that's a huge part of it as well, especially when you're starting out. You know, like that it's more critical for you to learn than it is for you to make more money. And you know, earlier out of my career I was working for a company that you know created Enhanced 911 software right that had provided some enhanced location data with it. And one of the rules that we had as an application specialist just helped us. You know, one of the rules was if we encountered something that we didn't know, you had a certain amount of time to troubleshoot it on your own. At that point, if you go over that point, you have to escalate it And then when you escalate it, you're not allowed to hand it off and just walk away. You're still on that call, you are still learning, you're taking notes and then you're taking those notes after the call and you're going back to the engineer that helped you and you're going through them to make sure that you're learning, that you're not encountering the same problem, you know, two, three, four times and not understanding the issue and whatnot. Right, and they, you know they had this rule in place and they said, like you know, if you ever break it, like that's just automatic termination, like we're not going to put up with that. We'll put up with you being dumb, but you need to be willing to learn.

You know, and that was just like a, that was just a rule or a mentality from the VP, really, and there was only one time this only happened one time where the new guy decided to like leave the call and figured that he was completely done. You know that his job was over And by the end of the day, i mean, he was gone. It was, it was like the the. I mean no, no one tested him before that. You know, no one, no one tested that that rule before that. Right, and I don't think anyone took it that serious.

But everyone knew that it was a rule and we all wanted to learn. And so it's like, yeah, we're going to do this regardless. You know, it's not even a question of if we're going to do it. It's like give me a minute, go get. I'm going to go get some water and I'll be right back, you know. But once that happened, it kind of like changed the whole, whole tone. It's like, no, this role is truly designed for you to learn. You know this Linux application better than anyone else in the world And that's why you're allowed to go on site at customers. It's because you know the code that's going on underneath and you have this low level title and I didn't you know. Looking back on it I can put all those pieces together, but when you're in it you know it's a. It's an interesting, different experience, i guess.

Yeah, And when you're into it you don't even, you know, you don't even realize that it's it's your learning, right? I mean the best, I think, the best times I learned let's say a funny story when I was in high school, you know, maybe senior year there was, there was electives and and I didn't want to do any of the electives. You know, i I was into my computers, i was into Linux, all this stuff, and so I proposed to the school that they let me do my own elective and I would build a website and a mail server and shared services for all the students, blah, blah, blah. And I gave them a whole list and they agreed to it And I got all that stuff done in like a few days. And then the rest of the year I have like 45 minutes or an hour to do whatever I wanted on the computer, and I thought I really got one over on the school because I got it all done quickly and then I had my own time.

Years later I realized that actually what I was doing with that time, to me it was fine, it was my time. What was I doing? I was coding programs. I was learning how to code. I was an IRC talking to people. We were trying to upgrade our kernels and do all these different things. To me that was fine, but in reality the school really facilitated me learning, And so did I get over on the number. Did they get over on me? I don't know.

Yeah, that's an interesting situation. So to kind of shift gears and talk about what you're doing now, I guess are you still at that same company as Optin9, the same company that you got into with your friend and you did all this kind of interesting work, Or where did Optin9 come into play?

Sure. So the company that we started was called WebAir. It was in the late 90s. We kind of rode that wave and grew with the industry as there was needs for web hosting. Then we just sort of kept adapting to our customers' needs. Eventually, almost 20 years later, we ran it. We had 50, 60, 70 people.

Then we really had to focus on hosting enterprise workloads, virtual private clouds, hosted private clouds globally, kind of transitioned away from web hosting. Web hosting was good to kind of really get your feet wet, dealing with tons of zero-day SSH vulnerabilities and having hundreds of thousands of IPs on the public internet, getting scanned constantly and all sorts of fun DDoS attacks. Web hosting is fine. We could talk about WordPress probably for days, but then we transitioned more to enterprise customers where compliance and security were more important, and customizing the infrastructure to fit within their framework for security and networking. That's where we kind of landed at the end mostly hybrid cloud deployments, a ton of off-site backups and disaster recovery.

Ultimately we sold the business two and a half years ago to a private equity firm, my partner. He exited. I stuck around just because I'm a geek and we're still building cool stuff. We ended up merging with two other companies one with the focus on AWS and one with the big presence in Canada. We renamed to Optinine. Today we're really still focused. Off-site backups and disaster recovery is a huge focus for us, as well as managed public and private clouds. It's funny every time I think we've kind of done everything, but there's no more runway. The technology is evolving. The third party technology is what our customers are trying to implement for their own needs. We have to keep up As there's new clouds that pop up and new SaaS platforms. Everything's getting more complex. People have more of a need to outsource, to manage. The providers like us to take ownership of those things.

Yeah, definitely. What do you think is coming on the horizon in terms of tech that you're going to have to be tackling to provide for your customers? I guess the first thing that would come to mind is some sort of AI integration with their own workloads and processes and something like chatGPT. It might even branch off into a more customizable solution for each business. Is that a route that you see the marketplace going down, that you're going to have to expand into and kind of learn and grow in, or is it somewhere else?

That's definitely part of it. We've used some of that new technology for some of our offerings. I'll give you an example. Being a provider that sells off-site backups and disaster recovery for our customers, we definitely noticed an uptick in that over the last two or three years. Some of it is sort of awareness and having to check the right boxes for auditors, for compliance officers. A lot of it, i think, is just sort of the awareness and ransomware attacks and security People obviously want to mitigate that. We realized if that's one of the reasons why they're consuming our disaster recovery as a service, how can we help them? How can we better address their needs? We're kind of thinking about that.

At the same time, we were noticing some of our customers actually getting ransomware. Prior to the ransomware attack taking place, we noticed the attackers once they would get into an environment they would be seeking out backup and replication tools and software so that they can destroy any possibility for recovery and then increase their chances of being paid the ransom. It was interesting because it's sort of like a new attack, like the backup software itself, the R-replication software itself is kind of this new attack surface that is under the microscope of these attackers and it never was before. The attackers are getting trained on the software, they know how to log in and change retention settings and disable backups and all. We realized that we actually had a very unique vantage point where, because of the service we're providing, we're actually pulling a lot of metadata about the state of their backup configuration and their replication. We actually built a service called Observer where we're taking all of that and we're running it through machine learning to provide anomaly detection where if you're not changing encryption settings normally or modifying your jobs, so we're moving VMs from backup configurations, changing retentions and all of a sudden we see activity like that. we can send you a threat notification, there's an anomaly and we see it's a suspicious activity. We built that and I think it's interesting because that is a layer of the stack that no other security tools are really looking at and if you can detect an attacker making those changes, you can almost predict and potentially mitigate an attack before it starts.

We built Observer. we did some cool stuff with it. We have it set up now to integrate into third party SIM and XTR tools. We have it set up so that if it detects a large enough or suspicious enough threat that it'll automatically air gap, the customers, offsite disaster recovery, environment and offsite backups, which is pretty neat. I thought that was a really good example of sort of taking, because you hear about machine learning. for me all these years it's very hard to discern what is shiny object, what is just sound school, what can I actually use for what I'm trying to accomplish for my job? We didn't force that down and just naturally came up. hey, here's a really good way to utilize ML for this goal.

That's really interesting. Your solution is able to air gap their environment from their backup solutions. Can you talk a little bit about, potentially, how that is accomplished or anything around that, because I find that to be really interesting. That's a really innovative solution. That I mean, obviously I've never heard of that before coming from really any other company that deals in the space of security or ransomware or anything like that. Even to go down that thought path of hey, there's an anomaly, we're automatically going to shield you from it in the event that this is real, even just having, i guess, that initial idea, is almost a stretch. You see what I'm saying. It's kind of like a stretch to even go down that route mentally when solving this problem. How did you guys go down this route and how did you kind of stumble upon this?

Yeah, i mean it kind of goes back to the first part of our conversation where it was based out of a need. We started noticing this with our customers and we had customers that had all their backups deleted and were ransomware, and then they would call us and say do you happen to have another copy on your side? We're totally rude And luckily, part of our service is get exposed to is go on a freelance or another one of these consulting websites and do people's projects for free or super low cost, because they're again. They're challenging you, they're putting a goal in front of you and it's going to force you into learning something. And when I've interviewed people over the years, yes, i look at the education, but I'm way more interested in what have you done? Tell me about the coolest thing that you've built. Flex your geek muscle and tell me how low level you've gotten or what you're most proud of. Maybe it's a project or maybe just some crazy issue that you have to have to troubleshoot that sticks out, but show me how deep you can get into the weeds And there are ways to do that. Like I said, go do a free project Back when I went to school too.

I kind of agree with you. I think there's much more specialized education these days, but I think up until recently, the education that you would get was sort of like a taste of all these different either coding languages or aspects of IT, and they kind of don't tell you. It's like hey, we're going to give you a class introducing you to all these different layers, but you should probably go home and dive deep into one, because who wants to hire a generalist at a college? You need to take that and we're giving you a sample. You figure out what you like, what you gravitate towards, and if you really like it, you're probably going to end up spending some of your free time doing it and build some projects And then when you go in for resume I think for an interview then you're really sort of marketable.

Yeah, i found when I was trying to get into security myself, that was one of the biggest hurdles, or even one of the biggest questions that was asked to me. The most even was what do you do in your free time? Like that's great that you know all this information and whatnot, but what do you do with it in your free time? Are you a nine to five security person, or are you a 24 by seven security person that is going to be researching different vulnerabilities in zero days and whatnot like in your off time? And I always felt that that was one of the things that kind of, i guess, separated me from the pack. That I didn't think of it at the time like that, but later on, talking to my hiring managers, they definitely took it like that, like even this podcast.

It's like an example of me trying to not only meet new people, learn new things, but also help the security community in a way that I wasn't doing it before. It's better when you do the extra work, when you do that little bit extra, because that's what's going to separate you apart from everyone else, at least in my opinion And you know you sounds like you agree as well That's what you're looking for as an employer. You're looking for the people that you know. I actually love what they're doing.

Yeah, absolutely. You know what that reminds me of is. You know, over the years you know I would have to text working for me and they would be dealing with customer issues And you know, oftentimes they would. They would troubleshoot something or try to fix it And at some point they sort of reach that threshold and kind of give it to me and say, hey, i'm stuck, i don't know what to do, i can't get this working, and that's all right. You know, send me the information.

And now it was on my plate And either either you know I figured it out or we lost the customer. They went elsewhere, and you know that's really good motivation, you know, and sometimes it's not convenient. I remember, you know weekends of just you know Windows Blue screen of death And like, either I figure this out or or you know losing revenue. And so it was great for me because it taught me. It taught me some really good troubleshooting skills, which is, i think, a skill that people don't focus enough on. But also it was good for me, it was good for the customer in most cases, but it was not good for the tech that kind of let go, because they're they're losing an opportunity, they're missing an opportunity.

And you know, one of the things that I think people need to realize is you know to what extent is your work environment playground. You know, for you to experiment and learn and teach yourself new things. Like if your, your boss, is giving you, you know, leeway or more time to troubleshoot or work on something to figure it out, you know and they're okay with that, then you should not be giving up or throwing up your hands. You know that's a gift And so when people have worked for us over the years, you know it took me a long time to kind of realize that that's an asset. You know we're we're, you know, working with us in similar environments, we're hosting different workloads for customers in different verticals and industries and they're using different IT stacks and applications.

That's a playground. You're getting exposed to all these different things. You're not pigeonholed. You're, you're, you're, you're. Maybe you're solving the same challenges often, but there's the same challenges in different environments, so it's always different And in fact, i've had a lot of people that quit and went to work elsewhere. You know big name companies and then they come back like, hey, you have any side projects for me? You know I'm kind of like getting bored. So I think people need to look at that too. Like, okay, you know, look at the comp, you know, look at your salary and all that, but to what extent do I have an opportunity to learn here?

Yeah, that's a huge part of it as well, especially when you're starting out. You know, like that it's more critical for you to learn than it is for you to make more money. And you know, earlier out of my career I was working for a company that you know created Enhanced 911 software right that had provided some enhanced location data with it. And one of the rules that we had as an application specialist just helped us. You know, one of the rules was if we encountered something that we didn't know, you had a certain amount of time to troubleshoot it on your own. At that point, if you go over that point, you have to escalate it And then when you escalate it, you're not allowed to hand it off and just walk away. You're still on that call, you are still learning, you're taking notes and then you're taking those notes after the call and you're going back to the engineer that helped you and you're going through them to make sure that you're learning, that you're not encountering the same problem, you know, two, three, four times and not understanding the issue and whatnot. Right, and they, you know they had this rule in place and they said, like you know, if you ever break it, like that's just automatic termination, like we're not going to put up with that. We'll put up with you being dumb, but you need to be willing to learn.

You know, and that was just like a, that was just a rule or a mentality from the VP, really, and there was only one time this only happened one time where the new guy decided to like leave the call and figured that he was completely done. You know that his job was over And by the end of the day, i mean, he was gone. It was, it was like the the. I mean no, no one tested him before that. You know, no one, no one tested that that rule before that. Right, and I don't think anyone took it that serious.

But everyone knew that it was a rule and we all wanted to learn. And so it's like, yeah, we're going to do this regardless. You know, it's not even a question of if we're going to do it. It's like give me a minute, go get. I'm going to go get some water and I'll be right back, you know. But once that happened, it kind of like changed the whole, whole tone. It's like, no, this role is truly designed for you to learn. You know this Linux application better than anyone else in the world And that's why you're allowed to go on site at customers. It's because you know the code that's going on underneath and you have this low level title and I didn't you know. Looking back on it I can put all those pieces together, but when you're in it you know it's a. It's an interesting, different experience, i guess.

Yeah, And when you're into it, you don't even, you know, you don't even realize that it's it's your learning, right? I mean the best, I think, the best times I learned let's say a funny story when I was in high school, you know, maybe senior year there was, there was electives and and I didn't want to do any of the electives. You know, i, i was into my computers, i was into Linux, all this stuff, and so I proposed to the school that they let me do my own elective and I would build a website and a mail server and shared services for all the students, blah, blah, blah, and I gave them a whole list. Whenever backups are deleted from our site, from the cloud, it does go into a recycle, an air gap recycle bin for a little bit of time. So we just started seeing it and we realized that because the backup infrastructure, backup software, replication software, is under that radar lens of the attackers, it's like this is a problem. So the way that we're doing it is and this is a larger conversation but a lot of people out there have a false sense of security when it comes to all of this right And should we know this right. They're like oh, i have an MSSP, so I'm secure. Or I have an EDR, i'm secure. Same thing. I have backups. I have a disaster recovery strategy, so I'm secure With disaster recovery and specific and replication tools. If an attacker gets into that tool at the production site, at the source site, by virtue of how that software works, if they're in that software, they can now control that software is writing to the target on the other side So they can just say delete everything. Like an attacker can destroy your DR capability in site in seconds.

Now, when people think about this, that a lot of times they start talking about well, what about immutability, Immutable data, immutable backups? And it's true, there is immutability, but that's with backups. It does not work with replication. So if you look at replication tools like your Zerdo's or your Wien's or your Combalts, they don't support that from a disaster recovery perspective. And so that's one right. And even with backups, right.

You hear these statistics about attackers being inside an environment for 60 days, 90 days, before they do anything or before people notice. And so same thing here. Let's say they can get into your backup tool I've seen them detect immutability and just turn off your jobs and wait it out, remove some servers from your backups and just wait for that immutability timer to run out and then brand somewhere to do So. The way that we deal with the air gap is very simple. We just change the credentials for the access for your offset, backup or replicas from the data mover, from the on-prem or production data mover that's sending the data, because that's where the attacker has access to, and so if the tool can no longer impose any changes on the other side, it's air gapped. They would have to call us in order to revert that.

And if you had a guess how many customers have benefited from this technology.

I would say many, and sometimes it's not just attackers, but this also plays into world employees. Sometimes, when we show the interface to potential customers and we show them all the factors that we're monitoring, everything that's going into the anomaly detection, they might look at that and be like, wow, it's really cool that you're looking at encryption settings being modified for your threat detection or retention settings being modified, but I'm the only person at my company that's supposed to be changing those things. If there's a change to encryption, i want to know about that right away. Please notify me right away. And then the other interesting thing about this is that many of the tools out there the backup software tools they can send out alerts. They can send you a notification when your backups don't run successfully or when your RTOs are not being met. But as a general rule of thumb, you probably don't want to use a tool to tell you when that tool itself is broken right Or from a security perspective, an attacker disables the tool, disables the server, shuts down the server, disables your S&TP service, whatever.

Now you're not getting those alerts. And so what we built is interesting because it's on the outside looking in. We're pulling that metadata, we're keeping it in our cloud And even if your entire environment gets destroyed, we still have all that data on that logs, and so it's really it's interesting to think about an SLA backed service which is beholden to notify you when X, Y and Z happens from software that you buy that has a capability to do something that you are responsible for maintaining right, and so I think it's interesting. I do think that concept longterm we're going to see it in other places.

Yeah, it's a different way of tackling this problem and even providing services. It's like a different level of service almost. You know, like I know there's a lot of vendors out there that kind of rely on their customers to tell them when something has gone wrong. Well, in that scenario, like the customer is already frustrated more than likely right, and working on help desk, that's always a tense situation. When you pick up the phone and you're already getting yelled at and it's 8 am, it's like I didn't even get through my first cup of coffee. Like can we slow down here a minute? So it's refreshing to kind of hear a company actually think about this a different way.

You know, and you mentioned something before with you know customers kind of thinking that they're automatically secure because they have an MSSP or some other you know managed service provider And I just I always have trouble with that, right, as a security professional, but just out of almost common sense, right, like it's an added layer of protection and nothing more. It doesn't. It's not the end all be all in your environment. You know, i worked for a company that didn't want to invest heavily into security and so they got an MSP. Well, with that MSP, we completely relied on them to tell us if there was malware in the environment, if there was anything weird going on in the environment, if there was no alerts coming in, the so-called security team basically had nothing to act on. And you know, for a while there was no alerts coming in.

And I just talked to the person who bought the solution. I'm like we're paying them all this money and they're not giving us any intelligence in our environment, like they're giving us nothing right, like there is stuff going on in this environment. I know that you think, or that you want to think, that there's no malware here, but it's a computer network, like there's going to be malware, you know, like we should be knowing about it. And it's difficult even today which is weird to say It's difficult even today to kind of break people away from that older mentality of I'm going to buy this solution and it's going to solve everything. Are you finding that to be a potential situation that you're having to discuss with your customers as well?

Yeah, all the time, And I think in some ways it gets better over time, in some ways it gets worse. There are just so many horrible assumptions out there, You know. A good example is people move their email to, let's say, Microsoft 365 and, and they agreed to it And I got all that stuff done in like a few days. And then the rest of the year I have like 45 minutes or an hour to do whatever I wanted on the computer, And I thought I really got one over on the school because I got it all done quickly and then I had my own time. Years later I realized that actually what I was doing with that time, to me it was fine, It was my time. What was I doing? I was coding programs. I was learning how to code. I was an IRC talking to people. We were trying to upgrade our kernels and do all these different things. To me that was fine, But in reality the school really facilitated me learning And so did I get over on the number, Did they get over on me? I don't know.

Yeah, that's an interesting situation. So to kind of shift gears and talk about what you're doing now, I guess are you still at that same company as Optin9, the same company that you got into with your friend and you did all this kind of interesting work, Or where did Optin9 come into play?

Sure. So the company that we started was called WebAir. It was in the late 90s. We kind of rode that wave and grew with the industry as there was needs for web hosting. Then we just sort of kept adapting to our customers' needs. Eventually, almost 20 years later, we ran it. We had 50, 60, 70 people.

Then we really had to focus on hosting enterprise workloads, virtual private clouds, hosted private clouds globally, kind of transitioned away from web hosting. Web hosting was good to kind of really get your feet wet, dealing with tons of zero-day SSH vulnerabilities and having hundreds of thousands of IPs on the public internet, getting scanned constantly and all sorts of fun DDoS attacks. Web hosting is fine. We could talk about WordPress probably for days, but then we transitioned more to enterprise customers where compliance and security were more important, and customizing the infrastructure to fit within their framework for security and networking. That's where we kind of landed at the end mostly hybrid cloud deployments, a ton of off-site backups and disaster recovery.

Ultimately we sold the business two and a half years ago to a private equity firm, my partner. He exited. I stuck around just because I'm a geek and we're still building cool stuff. We ended up merging with two other companies one with the focus on AWS and one with the big presence in Canada. We renamed to Optinine. Today we're really still focused. Off-site backups and disaster recovery is a huge focus for us, as well as managed public and private clouds. It's funny every time I think we've kind of done everything, but there's no more runway. The technology is evolving. The third party technology is what our customers are trying to implement for their own needs. We have to keep up As there's new clouds that pop up and new SaaS platforms. Everything's getting more complex. People have more of a need to outsource, to manage. The providers like us to take ownership of those things.

Yeah, definitely. What do you think is coming on the horizon in terms of tech that you're going to have to be tackling to provide for your customers? I guess the first thing that would come to mind is some sort of AI integration with their own workloads and processes and something like chatGPT. It might even branch off into a more customizable solution for each business. Is that a route that you see the marketplace going down, that you're going to have to expand into and kind of learn and grow in, or is it somewhere else?

That's definitely part of it. We've used some of that new technology for some of our offerings. I'll give you an example. Being a provider that sells off-site backups and disaster recovery for our customers, we definitely noticed an uptick in that over the last two or three years. Some of it is sort of awareness and having to check the right boxes for auditors, for compliance officers. A lot of it, i think, is just sort of the awareness and ransomware attacks and security People obviously want to mitigate that. We realized if that's one of the reasons why they're consuming our disaster recovery as a service, how can we help them? How can we better address their needs? We're kind of thinking about that.

At the same time, we were noticing some of our customers actually getting ransomware. Prior to the ransomware attack taking place, we noticed the attackers once they would get into an environment they would be seeking out backup and replication tools and software so that they can destroy any possibility for recovery and then increase their chances of being paid the ransom. It was interesting because it's sort of like a new attack, like the backup software itself, the R-replication software itself is kind of this new attack surface that is under the microscope of these attackers and it never was before. The attackers are getting trained on the software, they know how to log in and change retention settings and disable backups and all. We realized that we actually had a very unique vantage point where, because of the service we're providing, we're actually pulling a lot of metadata about the state of their backup configuration and their replication. We actually built a service called Observer where we're taking all of that and we're running it through machine learning to provide anomaly detection where if you're not changing encryption settings normally or modifying your jobs, so we're moving VMs from backup configurations, changing retentions and all of a sudden we see activity like that. we can send you a threat notification, there's an anomaly and we see it's a suspicious activity. We built that and I think it's interesting because that is a layer of the stack that no other security tools are really looking at and if you can detect an attacker making those changes, you can almost predict and potentially mitigate an attack before it starts.

We built Observer. we did some cool stuff with it. We have it set up now to integrate into third party SIM and XTR tools. We have it set up so that if it detects a large enough or suspicious enough threat that it'll automatically air gap, the customers, offsite disaster recovery, environment and offsite backups, which is pretty neat. I thought that was a really good example of sort of taking, because you hear about machine learning. for me all these years it's very hard to discern what is shiny object, what is just sound school, what can I actually use for what I'm trying to accomplish for my job? We didn't force that down and just naturally came up. hey, here's a really good way to utilize ML for this goal.

That's really interesting. Your solution is able to air gap their environment from their backup solutions. Can you talk a little bit about, potentially, how that is accomplished or anything around that, because I find that to be really interesting. That's a really innovative solution. That I mean, obviously I've never heard of that before coming from really any other company that deals in the space of security or ransomware or anything like that. Even to go down that thought path of hey, there's an anomaly, we're automatically going to shield you from it in the event that this is real, even just having, i guess, that initial idea, is almost a stretch. You see what I'm saying. It's kind of like a stretch to even go down that route mentally when solving this problem. How did you guys go down this route and how did you kind of stumble upon this?

Yeah, i mean it kind of goes back to the first part of our conversation where it was based out of a need. We started noticing this with our customers and we had customers that had all their backups deleted and were ransomware. And then they would call us and say do you happen to have another copy on your side? We're totally rude And luckily, part of our service is Now, you know, my emails in the cloud. I don't have to worry about x, y and z and people are shocked when I tell them that there's no, there's no backups of their, of their emails and Microsoft 365 and they have to go and consume that separately. But that's a service that we sell, so near and dear, are hard.

But you know, people just assume I'm in the cloud, i'm secure, i'm safe. They must have 10 data centers and you know, you know, obviously I'm sure you're right with a kind of shared responsibility model. So that's a big part. You know there's just so many bad assumptions. I think part of it is the vendors, companies like us. You know, the word cloud is just so vague, the word managed services is so vague. They allow the vendors to redefine them to, you know, based upon what they want, what they want to sell and how, and so you really got to read between the lines.

You know people ask us the wrong questions all the time instead of. You know they ask us do you have a SOC to type to audit? instead of did your audit yield any? you know, like exceptions or problems. The other thing, too, i think that people don't realize is complexity. You know, to the extent that you know your organization is going online and consuming SaaS products and clouds and different software, like You know that one of the primary goals of IT leaders today should be managing complexity and preventing kind of complexity. You know creep you to the extent you're focused on simplifying your IT stack is to the extent that you can manage it to monitor and secure it and scale it Right, and you got to manage that complexity. People some people just don't get that, you know.

Yeah, yeah, that is, that's very, you know, it's very interesting, right, as a cloud security professional, when people still have These misconceptions about the cloud. You know, like they, they just assume going into the cloud, whatever it is, will be secure and they won't have to worry about it. You know the best one is with backups to right, like they always assume, oh, the cloud is doing the backups automatically. Or You know, yeah, rs three bucket is replicating. You know we click this check box and it should be replicating, right, all these different things and it's it's.

It's frustrating, it's challenging, but I mean, i guess it shows that you know people like you and I will always be in business. Right, like, there's so many nuances. You know not to not to bash different people that don't understand this stuff as well as we do. There's so many nuances to this thing. I mean, you can, you can spend your whole career in AWS and not know everything about AWS. You know the same thing with Azure and every other cloud provider, or even technology. Right, it's just, it's just interesting how we develop these mentalities and then we kind of just stay within them, you know, over time, no matter what, almost.

Yeah, i agree, like you know, years ago or when I was a Teenager, people would say, oh, you're the, you know, you're the computer guy or her Jiro do computer or whatever. It's like if you were to say that someone. Now it's like a joke, it's like, well, what? what aspect? You know? it's like you said the, what aspect is it AWS? Which aspect of it It's? so it's so sort of localized now and this and the same thing, like if, if our environments are getting more Complex, if it's a mix of AWS and Azure And these different SaaS platforms and all that and IT teams need to manage that and secure that and monitor that It's it's nearly impossible.

And so I think it makes a big case For outsourcing outsourcing to best and breed that can own specific layers, and actually that's what we do, right, and so we're doing fully managed backups in DR, which is kind of like low hanging fruit, right, because it's not, it's not your credit, it's not your production environment. It's responsive to your production. You don't have to make any changes for your responsive and so Certainly for us, i think it's. It's a. You know, it's a growing market, but people need to like think about these things before they go out and start consuming a SaaS product Like will this fit into my resilience profile or my compliance profile? You have to think about those things Before you agree to buy something, not afterwards, you know years or months later when it's being used.

Yeah, absolutely. So. You know before, before we close here, if you had to give one piece of advice to someone that's trying to get into security, right, but they want to kind of future-proof their career to some extent, they always want to have a skill set that is in demand, that's able to, you know, get a job regardless of the economy and whatnot. What skill set would you tell them to really master and go into?

Yeah, that's a tough question. So I actually think it's very difficult to be An expert in security and IT security without really knowing, like you know, the underpinnings and and sort of the you know what's the architecture and what it's all living like. If you think of, if you, if you talked about, like, what makes a really good, you know hack or an attacker, right, there are probably folks that that you know, know how to code their coding, they know how to code to an extent, they know their way around. You know Linux or unique style operating system. They know what. They know their way around networking. Like you know, you need all those things to make a good attacker. You really need all those things to make a good security consultant.

Right, like it's very difficult, like it's very difficult to say that you're good in security if you don't know You know how TCP, ip works and how to do. You know, you know packet sniffing and you know understand, you know basics around Linux and so, as hard as it is to learn all of those things, and do you think that that folks need a really good foundation with how the internet works? and You definitely need some programming logic, you need to, at least you gotta learn Python or whatever. I don't care what language you learn, as long as you learn a programming language, because you just have to know the, the basic logic functions that exist in all of them. And so, like that in itself, i think, is important. Networking in itself is important. The more level you get with systems and or clouds, you will make you a better You know security expert. So I definitely think there is a place for that. Um, i also think there's a place for the non technical skills and this is an area that is always glossed over. You know the shiny objects and again, like same thing with networking skills, and you know basic coding, logic and systems. That doesn't go away. You know that transcends the cool aid of the day or the language of the day. Same thing with non technical skills being a really good troubleshooter. To the extent that you're a good troubleshooter, the language may change, the environment may change, but your ability to, to localize a problem, you produce a problem, Shilter out the noise or the. You know the, you know the symptom from, from the root cause.

Whenever backups are deleted from our site, from the cloud, it does go into a recycle, an air gap recycle bin for a little bit of time. So we just started seeing it and we realized that because the backup infrastructure, backup software, replication software is under that radar lens of the attackers, it's like this is a problem. So the way that we're doing it is and this is a larger conversation but a lot of people out there have a false sense of security when it comes to all of this right And should we know this right. They're like oh, i have an MSSP, so I'm secure. Or I have an EDR, i'm secure. Same thing, i have backups, i have a disaster recovery strategy, so I'm secure With disaster recovery and specific and replication tools.

If an attacker gets into that tool at the production site, at the source site, by virtue of how that software works, if they're in that software, they can now control that software is writing to the target on the other side So they can just say delete everything. Like an attacker can destroy your DR capability in site in seconds. Now, when people think about this, that a lot of times they start talking about, well, what about immutability, immutable data, immutable backups? And it's true, there is immutability, but that's with backups. It does not work with replication. So if you look at replication tools like your Zerdo's or your Wien's or your Combalts. They don't support that from a disaster recovery perspective. And so that's one right, and even with backups right.

You hear these statistics about attackers being inside an environment for 60 days, 90 days, before they do anything or before people notice, and so same thing here. Let's say they can get into your backup tool. I've seen them detect immutability and just turn off your jobs and wait it out. Remove some servers from your backups and just wait for that immutability timer to run out and then brand somewhere to do So. The way that we deal with the air gap is very simple. We just change the credentials for the access for your offset, backup or replicas from the data mover, from the on-prem or production data mover that's sending the data, because that's where the attacker has access to, and so if the tool can no longer impose any changes on the other side, it's air gapped. They would have to call us in order to revert that.

And if you had a guess how many customers have benefited from this technology.

I would say many, and sometimes it's not just attackers, but this also plays into world employees. Sometimes, when we show the interface to potential customers and we show them all the factors that we're monitoring, everything that's going into the anomaly detection, they might look at that and be like, wow, it's really cool that you're looking at encryption settings being modified for your threat detection or retention settings being modified, but I'm the only person at my company that's supposed to be changing those things. If there's a change to encryption, i want to know about that right away. Please notify me right away. And then the other interesting thing about this is that many of the tools out there the backup software tools they can send out alerts. They can send you a notification when your backups don't run successfully or when your RTOs are not being met. But as a general rule of thumb, you probably don't want to use a tool to tell you when that tool itself is broken right Or from a security perspective, an attacker disables the tool, disables the server, shuts down the server, disables your S&TP service, whatever.

Now you're not getting those alerts. And so what we built is interesting because it's on the outside looking in. We're pulling that metadata, we're keeping it in our cloud And even if your entire environment gets destroyed, we still have all that data on that logs, and so it's really it's interesting to think about an SLA backed service which is beholden to notify you when X, Y and Z happens from software that you buy that has a capability to do something that you are responsible for maintaining right, and so I think it's interesting. I do think that concept longterm we're going to see it in other places.

Yeah, it's a different way of tackling this problem and even providing services. It's like a different level of service almost. You know, like I know there's a lot of vendors out there that kind of rely on their customers to tell them when something has gone wrong. Well, in that scenario, like the customer is already frustrated more than likely right, and working on help desk, that's always a tense situation. When you pick up the phone and you're already getting yelled at and it's 8 am, it's like I didn't even get through my first cup of coffee. Like can we slow down here a minute? So it's refreshing to kind of hear a company actually think about this a different way.

You know, and you mentioned something before with you know customers kind of thinking that they're automatically secure because they have an MSSP or some other you know managed service provider And I just I always have trouble with that, right, as a security professional, but just out of almost common sense, right, like it's an added layer of protection and nothing more. It doesn't. It's not the end all be all in your environment. You know, i worked for a company that didn't want to invest heavily into security and so they got an MSP. Well, with that MSP, we completely relied on them to tell us if there was malware in the environment, if there was anything weird going on in the environment, if there was no alerts coming in, the so-called security team basically had nothing to act on. And you know, for a while there was no alerts coming in.

And I just talked to the person who bought the solution. I'm like we're paying them all this money and they're not giving us any intelligence in our environment, like they're giving us nothing right, like there is stuff going on in this environment. I know that you think, or that you want to think, that there's no malware here, but it's a computer network, like there's going to be malware, you know, like we should be knowing about it. And it's difficult even today which is weird to say It's difficult even today to kind of break people away from that older mentality of I'm going to buy this solution and it's going to solve everything. Are you finding that to be a potential situation that you're having to discuss with your customers as well?

Yeah, all the time, And I think in some ways it gets better over time, in some ways it gets worse. There are just so many horrible assumptions out there, You know. A good example is people move their email to, let's say, Microsoft 365 and Those don't go away. So try to find skills that transcend, like I said, sort of what's trendy right now. Look at troubleshooting as a skill that needs to be developed and learned. Technical writing being good at writing technical documentation It's not just an answer thought that you do when you want to be done with a project. You need to take pride. If someone else was managing the battle station at four in the morning and they read your document, can they figure it out without pulling you? There's these soft skills that will get you just as far as being able to fill your resume with 40 different odd languages or open source tools.

Yeah, that's a really good point. Actually, technical writing is underrated in my opinion. I learned this earlier on in my career, where everyone on the help desk would have their own kind of upgrade guides based on what they encountered, the different steps that they would have to do and all that sort of stuff. But mine was by far the most comprehensive because I would run into all of these random issues, things that people would even the developers didn't even understand how to troubleshoot, didn't expect what happened. all of that stuff.

Everyone would wait for my guide to just come out when a new release would happen, because it's like all right, if there's a problem, joe's going to find it. If Joe finds it, he's going to document it. to the most extent that you possibly could, i'd have screenshots. I mean, truly I wanted it to be someone where someone just coming off the street day one employee, everyone's on the phone and this guy has to pick up the phone and troubleshoot this problem or work through this upgrade. I wanted them to be able to refer to my guide and have all the answers right there And maybe they ask me a question here and there or something like that. But being able to have that in-depth detail is extremely important that I think a lot of people, including myself, even forget that that's a side of IT.

Yeah, absolutely Yeah. people, that's the boring stuff The monitoring, the documentation, the testing, the training. that's the stuff that gets glossed over, but it's really kind of make or break for many of these things.

Yeah, absolutely. Well, before I let you go, how about you tell my audience where they can reach out to you if they wanted to, where they can find your company and maybe if you're going to be at any of the conferences this year?

Well, hit me up on LinkedIn. That's probably the best place to find me. I have kind of unique names, so there's not too many of me out there who find me on LinkedIn. Conference-wise, i will be at Veeam on in two weeks, which is a conference. Specific to Veeam, which is a backup software, i mentioned the tool that we built for security. It sort of works with that. Beyond that, i'm not sure You kind of like this all last minute, to be honest, but hit me up on LinkedIn. I'd be happy to chat with anyone about any of these things offline or in the future.

Awesome Sounds great. Well, thanks for coming on. I really do appreciate it. I enjoyed our conversation. I'll definitely have to have you back on in the future. Thanks for having me. I look forward to it Absolutely. Thanks everyone.

Now, you know, my emails in the cloud, i don't have to worry about x, y and z, and people are shocked when I tell them that there's no, there's no backups of their, of their emails and Microsoft 365 and they have to go and consume that separately. But that's a service that we sell. So near and dear are hard. But you know, people just assume I'm in the cloud, i'm secure, i'm safe. They must have 10 data centers, and you know. You know, obviously I'm sure you're right with a kind of shared responsibility model. So that's a big part. You know, there's just so many bad assumptions. I think part of it is the vendors, companies like us. You know, the word cloud is just so vague, the word managed services is so vague. They allow the vendors to redefine them to, you know, based upon what they want, what they want to sell and how. And so you really got to read between the lines.

You know people ask us the wrong questions all the time instead of. You know, they ask us do you have a SOC? to type, to audit, instead of did your audit yield any? you know, like exceptions or problems. The other thing, too, i think, that people don't realize is complexity. You know, to the extent that you know your organization is going online and consuming SaaS products and clouds and different software. Like You know that one of the primary goals of IT leaders today should be managing complexity and preventing kind of complexity You know creep you to the extent. You're focused on. Simplifying your IT stack is to the extent that you can manage it to monitor and secure it and scale it Right and you got to manage that complexity. People some people just don't get that, you know.

Yeah, yeah, that is, that's very, you know, it's very interesting, right, as a cloud security professional, when people still have These misconceptions about the cloud. You know, like they, they just assume going into the cloud, whatever it is, will be secure and they won't have to worry about it. You know the best one is with backups to right, like they always assume, oh, the cloud is doing the backups automatically. Or You know, yeah, rs three bucket is replicating. You know we click this check box and it should be replicating, right, all these different things and it's it's.

It's frustrating, it's challenging, but I mean, i guess it shows that you know people like you and I will always be in business. Right, like, there's so many nuances. You know not to not to bash different people that don't understand this stuff as well as we do. There's so many nuances to this thing. I mean, you can, you can spend your whole career in AWS and not know everything about AWS. You know the same thing with Azure and every other cloud provider, or even technology. Right, it's just, it's just interesting how we develop these mentalities and then we kind of just stay within them, you know, over time, no matter what, almost.

Yeah, i agree, like you know, years ago or when I was a Teenager, people would say, oh, you're the, you know, you're the computer guy or her Jiro do computer or whatever. It's like if you were to say that someone. Now it's like a joke, it's like, well, what? what aspect? You know? it's like you said the, what aspect is it AWS? Which aspect of it It's? so it's so sort of localized now and this and the same thing, like if, if our environments are getting more Complex, if it's a mix of AWS and Azure And these different SaaS platforms and all that and IT teams need to manage that and secure that and monitor that It's it's nearly impossible.

And so I think it makes a big case For outsourcing outsourcing to best and breed that can own specific layers, and actually that's what we do, right, and so we're doing fully managed backups in DR, which is kind of like low hanging fruit, right, because it's not, it's not your credit, it's not your production environment. It's responsive to your production. You don't have to make any changes for your responsive and so Certainly for us, i think it's. It's a. You know, it's a growing market, but people need to like think about these things before they go out and start consuming a SaaS product Like will this fit into my resilience profile or my compliance profile? You have to think about those things Before you agree to buy something, not afterwards, you know years or months later when it's being used.

Yeah, absolutely. So. You know before, before we close here, if you had to give one piece of advice to someone that's trying to get into security, right, but they want to kind of future-proof their career to some extent, they always want to have a skill set that is in demand, that's able to, you know, get a job regardless of the economy and whatnot. What skill set would you tell them to really master and go into?

Yeah, that's a tough question. So I actually think it's very difficult to be An expert in security and IT security without really knowing, like you know, the underpinnings and and sort of the you know what's the architecture and what it's all living like. If you think of, if you, if you talked about, like, what makes a really good, you know hack or an attacker, right, there are probably folks that that you know, know how to code their coding, they know how to code to an extent, they know their way around. You know Linux or unique style operating system. They know what. They know their way around networking. Like you know, you need all those things to make a good attacker. You really need all those things to make a good security consultant. Right, like it's very difficult, like it's very difficult to say that you're good in security if you don't know You know how TCP, ip works and how to do. You know, you know packet sniffing and you know understand, you know basics around Linux and so, as hard as it is to learn all of those things, and do you think that that folks need a really good foundation with how the internet works? and You definitely need some programming logic, you need to, at least you gotta learn Python or whatever. I don't care what language you learn, as long as you learn a programming language, because you just have to know the, the basic logic functions that exist in all of them, and so, like that in itself, i think, is important. Networking in itself is important. The more level you get with systems and or clouds, you will make you a better You know security expert. So I definitely think there is a place for that.

Um, i also think there's a place for the non technical skills and this is an area that is always glossed over. You know the shiny objects and again, like same thing with networking skills, and you know basic coding, logic and systems. That doesn't go away. You know that transcends the cool aid of the day or the language of the day. Same thing with non technical skills being a really good troubleshooter.

To the extent that you're a good troubleshooter, the language may change, the environment may change, but your ability to, to localize a problem, you produce a problem, Shilter out the noise or the. You know the, you know the symptom from, from the root cause. Those don't go away. So try to find skills that transcend, like I said, sort of what's trendy right now. Look at troubleshooting as a skill that needs to be developed and learned. Technical writing being good at writing technical documentation, it's not just an answer thought that you do. When you want to be done with a project, you need to take pride. If someone else was managing the battle station at four in the morning and they read your document, can they figure it out without pulling you. There's these soft skills that will get you just as far as being able to fill your resume with 40 different odd languages or open source tools.

Yeah, that's a really good point. Actually, technical writing is underrated in my opinion. I learned this earlier on in my career, where everyone on the help desk would have their own kind of upgrade guides based on what they encountered, the different steps that they would have to do and all that sort of stuff. But mine was by far the most comprehensive because I would run into all of these random issues, things that people would even the developers didn't even understand how to troubleshoot, didn't expect what happened. all of that stuff.

Everyone would wait for my guide to just come out when a new release would happen, because it's like all right, if there's a problem, joe's going to find it. If Joe finds it, he's going to document it. to the most extent that you possibly could, i'd have screenshots. I mean, truly I wanted it to be someone where someone just coming off the street day one employee, everyone's on the phone and this guy has to pick up the phone and troubleshoot this problem or work through this upgrade. I wanted them to be able to refer to my guide and have all the answers right there And maybe they ask me a question here and there or something like that. But being able to have that in-depth detail is extremely important that I think a lot of people, including myself, even forget that that's a side of IT.

Yeah, absolutely Yeah. people, that's the boring stuff The monitoring, the documentation, the testing, the training. that's the stuff that gets glossed over, but it's really kind of make or break for many of these things.

Yeah, absolutely. Well, before I let you go, how about you tell my audience where they can reach out to you if they wanted to, where they can find your company and maybe if you're going to be at any of the conferences this year?

Well, hit me up on LinkedIn. That's probably the best place to find me. I have kind of unique names, so there's not too many of me out there who find me on LinkedIn. Conference-wise, i will be at Veeam on in two weeks, which is a conference. Specific to Veeam, which is a backup software, i mentioned the tool that we built for security. It sort of works with that. Beyond that, i'm not sure You kind of like this all last minute, to be honest, but hit me up on LinkedIn. I'd be happy to chat with anyone about any of these things offline or in the future.

Awesome Sounds great. Well, thanks for coming on. I really do appreciate it. I enjoyed our conversation. I'll definitely have to have you back on in the future. Thanks for having me. I look forward to it Absolutely. Thanks everyone.