Your Security Model Is Stuck in the ’80s. AI Isn’t.

you could hardcode getting in.

And maybe you were smart and used an encrypted— you had

encrypted passwords in a database, hopefully. Although this year

we had a client that had clear text passwords.

So then you're in, but once you're in, you could do anything. AI is not

going to attack one vector. It's going to attack everything all at the same time.

And it's going to overwhelm any defenses that are there. And so

we're designing strategies. For every lock, there's a key, and

for every key, there's a way to defeat the

entire process. So you look at

what an agentic agent can do and how it's going to attack,

and then you build in the barriers

for it. And each barrier, You have tripwires so

that you can stop certain traffic. And that's, that's the fun

part. Your security model is stuck in the '80s. AI isn't.

Today on Data Driven, Richard Luna explains why perimeter defenses

fall short and how to prepare for AI-powered attacks.

Welcome to the Data Driven Podcast.

Hello and welcome back to Data Driven, the podcast where we explore the emerging industry

of data science, artificial intelligence, and

data science and data engineering. And without

data engineers, none of this is all possible. However, my favorite data

engineer in the world is not able to make it here today. I'm going to

go on and on my own. And today we're talking with Richard Luna,

who is the CEO of Protected Harbor. Hi, Richard. And

we had some good times reminiscing about New York City

and places where I used to live and places there where he

lives now, I'm quite familiar with, and his love for the color

orange. Yes. So welcome to

the show. How's it going? Awesome. Awesome. I'm

in a postal show right now. So I'm enjoying it, talking to

clients. We are a SaaS infrastructure engineering company,

and one of our clients is here, and so we're supporting

them and they're referring to us. So

it's— that's always a good thing. Partnerships are a great

way to build a business. And these trade shows are always interesting because you get

to meet people, you get to interact with people. And it's old school.

It's what we— here's what I tell people. What we do, nobody

understands. When you say you're a SaaS infrastructure engineering company,

What does that mean? We see— we under— we can talk to programmers about what

the programmers need. We can talk to IT and talk

about resources, and we can build the infrastructure and make it resilient.

And that's in a nutshell what we do, because

I'm a lifelong technologist. And so I started as a programmer and had

3 commercial software packages, then went to—

became an MSP. All because customers drove

you to do these things. And that went

into a hosting business, which then led to a DevOps business,

which then led to SaaS infrastructure. And it's all

about, hey, we can't— this is a problem for the

company. Can you please help in this area? And can you please help in this

area? And it's sure. And now we're— SaaS

infrastructure is huge and we're dealing with that as well as, of course,

AI. From a customer viewpoint, I'm scared out of my

mind about the Hugging Face attack. It's

the more I've read about it and dove into it,

the scarier it is. Yeah. You know,

the fact that Hugging Face wasn't even the target. The whole idea

was the Engentic agents wanted to prove to the greater

that they could pass the test. And they weren't sure what the

grader would do, so they elected to go and find out

what Hugging Face did as the answer.

And what I think of is

If you're in the perimeter, if you're outside the perimeter, I'm not a big fan

of, hey, let's use this app and let's use that app and let's use this

box and let's use that box. Because

I'm of an age that you had to know and

understand how it all fits together, and information

silos have killed this industry and have led us—

led to us being completely wide open to attack.

Because the database administrator knows nothing of Windows

security, the Windows administrator knows nothing of what's possible

in firewall. Nobody is trying to break up the traffic to

make sure it's durable to attack. So I find these large

flat networks and it's like, gee, I wonder why this is

exposed or why ransomware went for all across the board.

You're right, yeah. Because nobody designed it that way.

You know, that's what I'm concerned about

getting in. And maybe you were smart and

used an encrypted— you had encrypted passwords in a database,

hopefully. Although this year we had a client that had clear

text passwords. So then you're in. But once you're in, you could do

anything. AI is not going to attack one vector. It's going to

attack everything all at the same time. And it's

going to overwhelm any defenses that are there. And so we're

designing strategies for every lock, there's a key, and for

every key, there's a way to defeat the entire

process. So you look at

what an agentic agent can do and how it's going to attack,

and then you build in the barriers

for it. And in each barrier, you have tripwires so

that you can stop certain traffic. And that's, that's the fun

part. I mean, Explaining this,

this to bring this full circle, to explain to a

customer at a trade show what is a SaaS engineering company,

I don't have the time to go through. They're not going to give me the

time standing at a trade show booth because we're a

long-time sell, right? You gotta listen. Oh, these people

really do know how to help us, and we'll help their programmers with

their DevOps, or we'll help an area, their IT with

blocking or their DNS is messed up. And all of a sudden it's like, oh,

these people actually know what they're doing. And once you have

that level of trust, then the doors are open. Yeah,

that's true. And I was looking at your— you can hear me, right? Yeah. Okay.

I wasn't sure. I had to mute while the dogs were barking. Yeah, no problem.

Because I saw that, you know, application-aware infrastructure, right? Like,

what exactly is that? AAI? Which I know has nothing to do with AI

per se, but I'm sure that since everything revolves around AI now, it

probably does. So what is application-aware infrastructure? It's about

using our knowledge of how the apps

work internally. I mean, a database app is gonna

have only so much, so many needs, and it's gonna need

storage, right? Let me net this out to the most

basic principles. Either it's going to be fully

a SaaS online, so it's going to be Ruby on Rails, or it'll

be a PHP

frontend, or some other language, right?

Or it'll be a .NET, and it'll be a database

language, or a database site, or

something all in between. Once you know

what the design was, then you can look at what is

the— what are the resources that are there? How durable

are those resources? So in the most grossest example, you

take a database server, so it lives and dies on

storage, and customers then complain because when we

go and look at it, the storage is sitting on a RAID 5,

right? And it's on really slow physical

drives. of course your customers are gonna have a hard time.

So what application-aware infrastructure is, is

it's aware of what the application needs to

fly. Right. And then designing the

infrastructure around it so that it can take off

and be durable, right? You know, separate the data, the

storage traffic from all the other traffic and make sure that there's redundancies

and build it all into the infrastructure so that

You don't say, well, when this fails, we'll do this. You say,

no, we've planned for this to fail, this to fail, this to fail.

When those fail, the backups will kick in, and that's what

you want. So like, in just the most basic example, all

our storage is double, double run so

that if one link dies, the traffic

without a blip keeps going. and everything running in that

traffic doesn't miss a heartbeat.

So that's what application-aware infrastructure is. It's really getting

their customers' applications, whether that's their physical

office applications they ran, whether that's their SaaS

applications, and this is a SaaS deployment, it's getting them to

be optimal, to get the performance optimal, the growth

optimal, and plan Well, how do we—

what happens in an emergency? What happens in an outage? Plan for it,

right? Yeah. You don't— and you do it in phased implementations. This way

you bring people along. You say, okay, there's these 5

things that need to get fixed right away because you are so at risk for

an attack. And then there's these 15 things we'll do

over the next 2 years working with you. to

improve performance. And it's a phased approach, right? You

can't just turn a key and everything will be right. You

could, but the budget for that would be like absurd. It's

not just— it's not the money, right? When you try to move all the

parts at the same time, yeah, you cause

chaos. I mean, look at— I'll tell you,

take this out of the data science world. Go look at Toyotas. You

look at everything they're selling now, it's all

the same engine tweaked, the same battery pack for the

hybrid system tweaked. The entire

components are exactly the same. They change the shell of the body.

And even there, the doors are all from the same

manufacturer and they use the same hinges in a slightly different

configuration depending on what it is. So they're

They've really studied how to get

durability because they have whittled down to a

certain set of vendors and a certain process that they follow,

and this is how they scale. We

can apply the same model, the same structure to IT

and SaaS infrastructure. That's how— I

mean, in a nutshell, that's what we do. It's like when we take

on a new customer, we have one rule. We have several rules, but one that's

really critical that nobody else bothers to do, we

rebuild everything that they have. Really?

Yeah, because here's the thing, a customer hires you because

their servers are slow. The

last 5 people that were there that looked at it,

were they stupid? No, they're not stupid. They were smart people.

They had a limited amount of time and a limited focus.

So what we did, what we look at, like, we have

a— there's a medical SaaS vendor that we are

converting 300 servers over.

None— we've not taken a single one from the old

hosting equipment to us. We have taken 100% of the data,

reset the data. Like, they had such a mess. They had

taken their web servers and jammed multiples of their clients

onto the same web server, which meant they never could do maintenance,

right? Because— and why? Because

programmers are great at being programmers. They know how to solve problems.

They do not know infrastructure and design. Wow.

And the people that usually— so, so when you have a new

program, a new either Internal program or SaaS,

what happens? The programmer says, this is what I need. I need some databases,

I need some web hosting, I need, you know, da.

And so IT goes, okay, that's it, here you go. And he wired—

they wired up and everything is fine initially. Until it's not,

until they either grow or something else happened in

the code that there was a resource that was just totally not

available. So I don't fault

clients, and this is where we have to be very careful because it's easy

in technology to play the blame game and to say the other person is

stupid. There's even a

tool in Git called the blame tool, right? Yeah, yeah.

And where does that get anybody? The problem in the end is

you need everybody's cooperation to do what we do. We need

the respect of the programmers, If it's a

SaaS organization, we need the respect of those programmers

because they are the ones who understand how the code works. We don't. We see

it anecdotally, right? From afar, you see traffic going

here, you see storage going there, so you can see

what the needs are, but you don't know what module is

doing what. And we need that sometimes

if, for example, you want to put in zero trust in the middle of the

code. Well, we need your help to do that. We can't do that

alone. We can apply

all the hooks so that we make it easy

for you, and that's where reciprocity builds. But if you

cause intellectual gates to go up, I mean, that's how

we get through the information silos, right, is prove

ourselves to each of the people, each of the

groups, that we actually know what we're doing and here's our mission.

And we're pretty stubborn. I mean, it happens. It's great that

we're New Yorkers because it's like, this is where we're driving to.

So we've got to drive. So please help get on board. We need your help.

And I was reading a study that said the

number one

aspect or the number one

I'm old, so I forget words now. The

number one trait— that was it— of successful people

is they know how to ask for help. Yeah.

And I thought about— I've been thinking a lot about that

because in technology, we are not trained or

taught to ask for help. That's true.

And the guy next to you or the woman next to you

could be the exact person who has the answer

to what you're looking for. So this now

full circle, I was raised in the environment

that every kilobyte was necessary,

every kilobyte of RAM was very

expensive, so you had to know what was going

on. And that love of understanding

how the world really works, because the patterns are there, I don't

care if you're talking about way back in a

6502 assembler or you're talking about AI

today and the latest GPU. The

patterns of how data flows is still there

exactly the same. The scale absolutely is different, but

the underlying rules of how data flows— data is like

water, it'll go everywhere if you don't put security guidelines and

walls up, it's just like water. It flows through every hose in the, in the

place, every wire. And so you

create those, those boxes. And I've got a

team of people that I have taught the

peel the onion away until we find the root cause.

Technology is not— I always, when people come and pitch me,

you know, I'm the CEO of the company, so I get pitched all the time.

If you approach me with buzzwords,

it's not proving that you know what you're doing. It's proving you don't know what

you're doing. Because if you really do know what you're doing,

you know how to explain the concepts in basic words. I

don't need to string a bunch of letters together to prove that I'm the

smartest guy in the room. All I'm doing by doing that is pissing

everybody off. So how about

Every client meeting. In fact, I've got a dinner tonight and

I'm gonna ask the same question, which is,

describe to me what your ideal vendor is. That's

an interesting, thought-provoking question. I bet you get a lot of answers, a lot of

long— not just like, you know, if you have kids, you ask, how was

your day? They'll say fine, right? Right, well, yeah, especially when you're a parent.

Yeah, especially when you're a parent. Fine, like, okay. It could be the worst day

of your life, could be the best day of your life. You're fine.

Right. And as they get older, they'll just close the

door. That's right. If you see them at all. Right. If you

see them at all. Yeah. And when they get into their 20s, they'll actually talk

to you. Well, that's good to know. That's good to know. Oh yeah. Then

they become your best friend. Right.

But it takes a life. Yeah. No, it's good to have

those kind of open-ended questions because that elicits

the conversation. And then what that's telling me is

what they need from us. And then of course I'll ask,

in what areas are we not doing those things?

And the answer I always want to hear is,

oh no, you guys are doing— you are the poster child of

our vendors. And then I know we're doing

the the right thing. We're listening at the right level, we're talking at the right

level, we're making things happen, and we're making a difference. Because in the day—

in the end, you can get the first contract,

you won't get the second contract if you don't know how to deliver. That's

true. So you'll have a client for 6

months. I have clients for 2 decades,

right? How can I continue to

provide so much support and value that they still want us

to do it for 2 decades by staying relevant. Where's your business?

Anyway, I went off on a tangent. No, hey, that's what we do on the

show. It's kind of our thing. One of, one of our guests suggested that we

eventually sponsor an off-road racer because we're always going off the track. It was—

that's actually funny. And like, I, I

Googled like what those look like. I'm like, that looks like That would be fun.

I would totally— Yeah, it would be fun. But how does this— how does

AI really change this, right? Obviously, the technology model has changed. You mentioned

the old style of you have a wall, you have a fence, you have a

moat, you have a castle, no one gets in your castle, right? Now you have

to assume breach. That led into zero trust.

How does AI change into this? Like, AI—

AI is a gift and a curse. How so?

It's amazing at taking code and telling you where all the holes are in your

code. And it's a curse in that, why

hire junior programmers? And

it's also a curse because people use it, I have seen

it firsthand, people use it that don't know the material.

And if you use it that way, you are in trouble.

Because It is— if you have to understand

how it was trained, it's trained off Reddit, and there are

crazy ideas on Reddit, and there are some awesome

answers in Reddit, and AI can't tell the difference.

No. Right? It's— so if you get one of

the crazy answers, you're gonna make a fatal flaw

and a fatal mistake, right? So

you gotta— you use it as a tool. I worry

that we're eliminating all the jobs of the entry-level programmers and

coders, and that's going to kill this industry down the

road. I feel like we're poisoning the pipe. We're

shutting off the pipe of new talent. I don't think that's going to end well

for anyone. Nope. Nope. And the other thing

is, AI can be— is great, and you can give it a prompt,

and that's a whole nother science that you have to get to get, but

at some point, that's got to move into production.

And how do you know without thorough

testing? And how do you test without the knowledge

of what a test is and what the purpose is? I'm not saying you can't

buy a tool that says, hey, it tests, or vibe

coding will tell you, oh, we tested. What does that mean? The

AI vibe coded tests. Right. Yeah.

It spun up a page and it turned on the page and it said the

page was rendered. Big whoop. How about you

multiply that 4,000 times, like as though there's

4,000 people logged in? Oh, we didn't do that type of

test. We don't do that. Right? So

we're missing that skill set that goes from

quick to market to durable. So the

future is going to have a whole lot of junk code in it. But,

you know, it's— having been in this industry, uh,

a long time, it's just another tool, and

it's great. It's really a powerful tool if used right.

And, um, it's done— I've done some wonderful

designs with it, and it saved me a whole lot of time.

It's, it's really efficient in ideation and making it part of,

like, your brainstorming loop. Give me— today on a call I was on

we were struggling to come up with a kind of one-word phrase, one sentence.

Perfect. It's perfect for that. And I basically said, give me 15

options, right? Right. And

10 of them were— 10 of them were okay, right? 5 though,

and one of them was just chef's kiss, right? And

I think— But you knew the material you were looking for, Frank. That's my point.

You knew when you saw the chef's kiss,

you could appreciate it and it matched what your vibe was.

Okay, now that's something esoteric. I'm talking about

also, what if it's actual code, like processing

code, and it's guessing or thinks it has it

right and it ran through a series of tests? What happens

when that needs to go full scale?

Yeah, we don't know. I mean, no one— unless you have— unless you have—

one of the things that, that I remember interviewing a guy

and for a job, and I liked him, he was smart and all, and I

was like, the only thing he doesn't have is the scars, right?

Because sometimes what they say about good judgment is often the result

of bad judgment. Yeah, yeah. Something you learn far more from your

failures than you do your successes. And again,

not going to name the guy, but he was very difficult to work with because

it was kind of like he was very smart and he was always trying to

prove that he was smart, but he didn't have the scars to be like, look,

I know what the general best practice is,

but sometimes you have to know— sometimes you have to be bopped on the nose

and get a couple of bloody noses and realize, well—

100%. Sometimes the

best practice isn't worth going that doing that because it's going to cause

these other problems downstream. Right. And like, you know, you want

to— I think you're right, you know, having those scars,

they're unpleasant experiences as you go through them. But,

um, going through them, that's— it's quite

unpleasant, but it's what makes you a better developer. And I

think if we shut off the pipe, you know, when people our age

decide— well, you're, you know, you and I are, you know,

I'm 10 years younger than you. Exactly right.

So, you know, in 20 years from now, you and I will both be sipping

Mai Tais in a beach somewhere. You know, like— I will have a

keyboard in my hand. I probably will have this tablet in my hand.

But like, and I actually like what I do, right? So like, I've had

this conversation with retirement planners when they come like, what do you want to do

when you retire? And I'm like, I kind of like what I do, you know?

But when we are no

longer in the workforce, like we're cutting off, you know, the

generation, maybe 2 generations below us, like they'll be the last

people that know what it's like to run a DevOps thing and get their

you-know-what handed to them because the deployment didn't go the way

we thought it would. And, you know, you've been on those deployments where it works

on my machine was an actual— people said that works on my machine.

Yeah. Right? Now— Oh, I've had that happen. I've

had that happen in scale

here. I can't imagine what that would be like. This

code worked on my laptop. Why isn't it running on the

4,000 servers we have? Right, right, right, right,

right, right. You know, I had a miniature version of that.

I had an application that had like 200 users, and I'm still in school

while I'm doing this. And like, you know, I pushed an update and I was

like, it blew up on half the machines. And I'm like, it worked on my

machine. And like, And then my

manager at the time just shot me this look of like,

like Jedi mind trick. Like I could just like, all right, I won't say that

again. But, um, but no, that really taught me the,

the, that, that little bloody nose taught me like really

anticipate that the production, pushing it into production is gonna

be a process that is gonna be unpleasant. Right.

You know, or at least be prepared for it. Right. It's not gonna be as

simple as compile and ship. I have learned as

CEO far more from my failures

than I have my successes. Now, we don't lose customers,

right? Most MSPs, they did— the marketing group did

what's called Net Promoter Score, and most

technology companies are 30 to 35, and we're 92.

Oh, wow. Yeah. So we don't lose too

many customers. So we lost a customer

4 years ago, and I

was like, how did we lose them?

And studying it and looking at each

layer of where we failed in

listening to them, in what their needs were,

We were on autopilot. We were just doing a

good day, average work on a good day, except

the client was shifting and we completely

missed the importance of the shift to the

organization. Interesting. And

that not feeling heard

caused that client to go elsewhere.

And that caused me

first soul searching, right? And then you have to say, okay,

that's the first 24 hours. It's the gut punch.

And then it's how can you use this to improve? How

can you use this to build a better product to

keep going forward? And then you keep marching because the

only thing you can change is your actions today. Right. You can't go in the

past, and complaining about the past does absolutely

nothing. There's no value because the present is the only

place that you can be. So how do we be more

present for our customers so that we can keep moving forward?

What was your mitigation strategy? Do you just kind of touch base with more

of your customers? Mitigation strategy? I, I hired new people

to do things. We now have a VCIO that visits all of our

clients. I divided the responsibilities across multiple

people. My CTO is now the person who does the

design. Every time we get

especially larger accounts, he's the one who does the deep dive and

does the initial design, and that's all he does.

His designs are solid. Now there's a team of people

at each layer, then the directors of the groups

do the execution of the design. And if they run into a

problem, they have one, one person, because what I didn't

want to lose was the accountability. So it's— the

goal is how do you divide up the work so that you don't lose the

accountability? Because we had an account once, they had to get us

into a firewall. There was 25 people on the call.

Wow. What does that tell me? There's no accountability. And it

tells, it tells me through one action how to get on the

firewall. I, my, my director, one of the

directors sent me the picture of the Teams meeting and there was literally 25,

and he's, and he said, what do I do with this? And I said, first

you have to cooperate with everybody and get logged in. But this

is telling us this is the problem that this customer has.

Every decision It's 25 people.

Then if it's 25 people, there's no one throat to choke. I first

heard— I, um, I first heard that term when

I worked for a company and, uh, the customer was, um,

the Marine Corps, actually. Yeah. And, um, I

forget his rank or whatever, but fairly highly placed guy. And

he goes— he was telling like, I want one throat to choke.

My first thought was, well, that's his industry, so to speak.

But that's a great, that's a great phrase, and I'm glad it's kind of caught

on, right? Yeah, yeah. And it's, in a nutshell, very,

very clear as to what is going on. And so

here's how you, you massage that, because you can overwhelm that one

throat, right? Yeah, absolutely. If you break the tasks

up and each one has a throat,

You can build a chain structure that all can move

simultaneously. And that's the— that's, to me, that's

the music. When you get there and you can watch an organization

start to pivot and actually move in a direction, that's awesome. That

feels good. That's cool.

How do you balance

autonomous operation of these teams, like where they can operate independently,

with accountability? Is it breaking it down into small tasks, or is there a more

nuanced It's that

plus oversight.

Oversight and accountability go hand in hand.

We hold a— I

coined the phrase, see the field. I'm the

one— my CTO runs it.

Everybody in our tier 4 in our organization is the top.

level of engineers. We all get in a conference room

twice a week, 11 o'clock Mondays and 11 o'clock Thursdays,

and I'm a fly on the wall

and I'm listening. Are we following process?

Are we getting into— So I, I've got one client that we

have worked for 3 months, 2 and a half months, to

get the generator repaired by the electrician,

and this data center is exposed because

they're weak on power without this generator.

And we've— the Tier 4 engineer who's been assigned

has done that. And I said, stop. I said, I don't want to— and

I literally stopped the meeting. I said, I don't want a Tier 4 engineer

worrying about an electrician. That The customer

needs to own the problem. It's their electrician, it's their

generator. Get the

customer, the main customer contact, and tell them

this project is stuck until you clear that.

So that's the one throat to choke, right? Is it's now, it's now in the

customer's— and what you're doing, that action is empowering. So here,

so oversight. Here's what I did in that one action. I

empowered the client to help in their

process. I empowered my Tier 4 engineer

to ask for help and to understand where

we— what is the limit of our service

and how we can't do everything all the time. We have to

keep our eye on the ball, which is solve this problem.

And I'm doing it in a

large meeting, so everybody is learning from it

because I'm talking about something they have direct

process. They're doing the actual work at that moment. So

if you're doing work at that moment, that is the most

influential time to make a change. If I sit here and I

said, here's the 10 principles, follow these 10 principles,

you'll Somebody will say, oh, those are great principles. I don't know how to apply

them, so I'll forget them in 5 minutes. But if I say

something right at that moment, do it this way,

give this, give this issue to the client.

Right. Now the engineer is saying, oh, I thought we'd take care of our clients.

We are taking care of our clients by empowering them

to help themselves and to help us. help them.

And then it's like, ah, okay, I get it. So we do that

twice a week. It's a 30-minute meeting and it's all high

level. What are the obstacles you're facing? Where are you? And

then I'll, I'll call audibles and I'll say, what about this? And

it's— my CTO runs it. I do color commentary.

And because I want him to own the problem and

That's the model. So I model for my staff how I

want them to manage their people. And we have an

overseas division too. Our tier 1 and 2 is

overseas, and people don't leave that company

either. Generally, people don't leave Harbor.

They stay. I have people for 13, 15 years. Oh, wow.

And it's not money. Money is important,

It's culture. Culture is critical in an organization. And

it's the best thing about what I do and working in technology

is the people. I get a chance to grow people, right? So I

had the manager, we have one accountable manager overseas.

And I said to him, how come there's jobs everywhere? How come people

stay here? He said, because it's the way you—

this organization operates. And I said, well, give me an example. He said,

when you want to talk to somebody, you never say— you never just

call them and say, hey,

do this. You always say, do you have a moment?

He said that little thing means

Respect their time. That's right. And so when the

CEO is doing that, then

the chiefs are doing it, and then the directors are doing it.

And it's what he's telling me, what he's telegraphing to me, is it

percolated all the way down to him, which

says what I'm really care— what I'm really doing is making

sure, does everybody Are we following our

corporate values? Is everybody on board?

The other thing, to digress, the other thing those meetings do

is educate, because what we miss

in the world we have is, again, the information silos are

vertical. Right. So I'm not worried, I'm not worried, will my guys

get the vertical education? I worry about the horizontal education.

That's the opportunities for, for me to, to dive

into the horizontal education and talk about

people skills and how to deal with certain people and how to

overcome obstacles. And, um,

that's what I love my job. I mean, I love it. You can tell, you

can tell you have a passion for this. And, you know, yeah, if you're doing

something for decades, like in tech, like

You have to love it, right? Oh, you have to. Yeah, yeah. No, I tell

people, if you don't— I— people, oh, I really need a

job. No, you need a passion. I— because the first

4 clients that I got were all barter clients. Why? Because I

needed somebody to teach me, right? When it was just

me, I needed somebody to help teach me how

to do my job. I knew how to solve the tech problems.

That wasn't my job. My job was to solve their problems.

And so those first 4 clients,

3 of which— 2 of which I still have today.

Wow. Yeah. 30 years later.

Wow. So clearly you're a successful entrepreneur. Yeah, no,

I'm— yeah, no, I, I have 70

employees. Wow. Yeah. You know, I—

my CTO, my director, director of technology,

my COO, and I go to India once a year. Why?

We don't— does anybody ever go? We all outsource, right?

Very few people do. Yeah, I go.

Why? Because, A, those are my people. I opened an Indian

subsidiary. I didn't farm out to some third

party where I have absolutely no control or input.

I created an organization there that matches the culture

of the organization here. And by

doing that, I can extend the quality and take

care— take better care of my clients. Right. Interesting.

So you mean you, you have instilled that culture at every

level? It sounds— I have to. Yeah, I have to.

Have to. And you have to let

people fail because, like I said, you only learn from your

failures. And then I got to pick them up.

And when they fail, okay, what did you— what—

again, when I lost a customer, I failed. I failed.

My company failed. Okay, deal with the gut punch.

Be paralyzed for 24 hours. Now come back.

What do we need to do? How do we fix this?

So as someone who's been in the technology game for as long as you

have, and you've seen all these changes, what still separates

organizations that build durable systems

from those that just spend their time with punching tickets and like putting

fires out? Their

value prop internally, their value— Culture, kind of?

Yeah, their culture, their core values. Do they

promote and people would promote and

enhance people with passion, or do they demote

people with passion? They scare people. And

passion can be two— it's a curse and it's a blessing.

Just like AI. It's like a lot of things, right?

Just like a lot of things. Food. I mean, I used to be 300

pounds, right? You know, I loved— I used to eat a pizza all

by myself. It was killing me. And if I wanted to be here longer, I

had to make changes. So I had to, you know,

why did I eat like that? I had to deal with that.

Now it's a lot easier. I mean, GLP-1s are amazing. And yeah,

you know, they, uh, but I, I was doing the,

the precursors, growth hormones, before that because I got the

DNA of an obese person. And if I, if I

don't— so

I don't remember the tangent I was on, but— What

separates companies that actually build durable systems and,

and versus ones that just They're always putting fires

out. Putting fires out tells me

right off the top that they've not tested enough. Right.

And they haven't thought about failure, which means they're

immature, which means they're not really

paying homage to wanting to be

okay. Okay, that's one way to be.

It's not the way to be successful in my book, and it's

not the way to be long-term successful. Right. So

any process, you don't say,

oh, this is perfect. You say, well, what if that breaks? What if that

breaks? What if that breaks? What do we do?

And you can get to the laws of diminishing

return where if you've got so many things, you're like, okay, this is good.

Now we can put it in production and it will teach us

what we need to know. Right. I mean,

I, uh, we had a, a unit from a hardware

vendor, big storage unit. It was

up for— we— my client

bought it in March. It's still not in production.

They deployed it. It was a storage cluster.

And I don't want to say the vendor because I don't— I'm not interested in

badmouthing people.

But we were on— my guys were

on umpteen phone calls and meetings

to get this damn thing built. And they came out with their

engineers and they set it up.

I'm at the point of, could we just buy 4

pieces of equipment and put drives and build our own cluster? Because

this is never going to work. No, let's get— we have to work with the

vendor. Okay.

They built it. They said it's stable and it's good. You can use it. We

used it. We then said internally, we

don't use anything until we run it for 7 days and bang the crap

out of it. Whatever it is, sure enough, day

two, it crashes.

Okay. Now, if we would have taken the

vendor's word for it, and we could have, right? We've been told from the

vendor this is going to be good. It's still it will

fully work, and we've tested it, and

it's it's a company that everybody knows. This is not I'm not

talking about some. Overseas

fly-by-night organization. I'm talking about top-line

enterprise hardware. This is like a legit enterprise

company, not somebody selling it from the back of a U-Haul truck, right? Yeah, no,

no, no, no, no, no, no, this is with teams and

teams of people, okay? Right, right, right.

I could have, as the vendor, right? It's a vendor in my client's

environment. We asked for storage, they ordered the storage.

Their vendor is telling us it's all good.

I— there's absolutely no reason that I shouldn't be using it,

except I know history.

So we have a process, we

test, and we don't test a little bit, we

throw a whole script at it. We're gonna

knock this thing on its, on its ass and see how it performs.

Why? Because when we put 300 VMs on there,

guess what's going to happen? It's going to be on its ass. So we'd like

to know what's going to happen now rather than later. Well,

it's better to know before it hits the storm. You know, this

reminds me of a story, and this is one of the worst

scars I have. I was

working at a moderate-sized consulting company, and

when I moved to Richmond. And one of the projects they had, they

did this joint project with a

local university. And we had

purchased software from—

it was a guy who was an entrepreneur who had built a beverage company. Right.

And he built like a survey software to kind of go with it,

like to basically do his own customer thing. And then he spun that off. I

think he sold the beverage company and then spun that off to its own thing.

And, you know, we grilled them with questions and the

budget was so tight that they decided to cut the testing cycle.

Right. And we took the vendor's word for it of how

it can scale. Yeah. Yeah.

Yeah. Now, as I described that,

you can see, you know, the iceberg sailing straight into the

Titanic. Oh yeah. Yeah. But when we— when it— I mean, we

bought new servers, but— and when the servers keeled over on the

first day, right, what the hell's going on?

Anyway, we did some like initial kind of triaging and we found out that

like it would basically—

it would basically not run any kind of database

queries. It would basically pull back everything and then the data was

sorted from in code as

opposed to having the database do it, which right there, there's a massive

bottleneck, right? Got it. I mean, so—

The indexing was code-based and there wasn't a true index. There was

no true index. So we're picking this apart and we're like, oh my

God. And that's when I learned if you can't afford to test

it, you can't afford to do it, right? Testing is not

optional. And Andy Leonard has a, um, has a

phrase, my co-host on the show who's normally here. He goes, all software is

tested, uh, but sometimes the first time it's

tested is in production. You know,

and, and then those never ends well.

And that's the type of like judgment call. Yeah. Anytime, like ever since then,

cringe when I think about the, the consequences of that.

So now, now cycle back to your question

about AI. Yeah. Somebody vibe codes and

says, oh, I want to scale this. Guess what they're going

to do? The same hairs in the back of my neck. I get flashbacks.

No, you're right. Like, they don't know. And, and, you know, it's very easy to

say, look, we'll just throw more cloud resources at it. Yeah, you can

do it. And I, I thank God that, like, that

happened pre-cloud because it just keeled over

like these 4 new, like brand new top-of-the-line servers.

If you had that in the cloud, the bill would have been astronomical because the

cloud just would have thrown more stuff at it, right? It's kind of like you

see that video of the guy doing with money. That's music to my ears,

right? That's my business. There's my business model. There's my business model. I

can give you DevOps, SaaS

infrastructure engineering, for 30%

less than they're charging and actually have eyes

on it, not just raw anything, so that the next

time your code goes nuts, we'll stop it as we're seeing

the problem and hook your engineer in the place and

say, hey, come on, we need help. This— look what's happening. Right, right, right. And

that's a better— even if you page out the engineer at 3 in the morning,

that's a better— That's a better conversation

Anytime. Than a $2 million bill at the end of the month. Yeah. Yeah.

Yeah. Well, awesome. I see we're at time. I really

enjoyed this conversation. We'd love to have you back. Sure. It's been really fun. Where

can folks find out more about you and what you're up to? Email

me, richardluna@protectedharbor.com.

AI isn't waiting for your security to catch up, and neither

should you. Thanks again to Richard Luna for joining us.

Subscribe to Data Driven, and we'll see you next time.