The Journey of a Linguist Turned IT and Security Professional with Jeremy Snyder

1 00:00:01
Speaker 1: How's it going, jeremy?

00:00:01
It's great to finally have you on the podcast here.

00:00:05
It's been definitely a crazy couple of months for me with a

00:00:08
new board and whatnot and getting used to that whole thing

00:00:11
, but I'm glad and excited to finally have you on.

00:00:15
Speaker 2: Well, first of all, congrats, Joe, and second, thank

00:00:18
you.

00:00:18
It is a pleasure to be on here.

00:00:20
I remember when my kids were little.

00:00:22
I know what a difficult balancing act that is.

00:00:25
I'm at the other end of the journey.

00:00:26
Mine are now 23 and 19.

00:00:28
So I don't really miss those days, in a way, but at the same

00:00:32
time I kind of do.

00:00:32
They're a lot of fun when they're little.

00:00:35
Speaker 1: Yeah, from what I hear, it's like you miss it when

00:00:38
they're little, like them being so little, but like the

00:00:43
struggles up in the middle of the night, no sleep.

00:00:47
And yeah, you have to do a full workday.

00:00:50
Right, it's hard.

00:00:52
Speaker 2: Yeah, yeah, and it's not always a normal workday,

00:00:55
right Like when you work in IT and security, as we all know,

00:00:58
you're always kind of carrying a pager, whether it's a literal

00:01:01
one or a figurative one in the form of, you know, slack and SMS

00:01:05
notifications for things that you got to pay attention to.

00:01:07
So, yeah, I wish you the best in the journey and, again,

00:01:12
congrats.

00:01:12
It's got to be, enjoy the time.

00:01:15
Speaker 1: Yeah, thanks.

00:01:16
So, jeremy, you know I start everyone off with getting into

00:01:21
how they got into security or IT overall.

00:01:25
The reason why I start there is because I there is a section of

00:01:30
my audience that are trying to get into IT or security and I

00:01:35
feel like always hearing someone's background is helpful,

00:01:39
right, because maybe it's, maybe it's that background that

00:01:42
matches up with them and they can hear like, oh, this is a

00:01:44
possible thing for me, which is it's interesting, because I've

00:01:49
done probably over 140 episodes by now and I haven't heard the

00:01:54
same background once.

00:01:56
Speaker 2: Yeah, and I don't think you're going to hear the

00:01:58
same background from me there, because my upbringing was pretty

00:02:02
weird, in many ways Super nomadic.

00:02:04
By the time I finished high school I'd lived in four states

00:02:09
and four countries, spoke a few different languages, went

00:02:13
through a very circuitous journey through college,

00:02:16
actually dropped out of college twice, once here, once in

00:02:19
Finland re-enrolled and completely changed directions in

00:02:24
my studies partway through.

00:02:26
And without going through all the details of it, to answer

00:02:31
your question, how did I end up in security?

00:02:33
I kind of failed into it in a way.

00:02:35
So after that second time of dropping out of college, I moved

00:02:40
back to the US from Finland where I'd been studying chemical

00:02:42
engineering, and I decided to study linguistics at this

00:02:47
program at University of North Carolina where they had kind of

00:02:50
this intersection of computer science and linguistics called

00:02:53
computational linguistics really worked well for my background.

00:02:56
I had a lot of well, I spoke a few different languages pretty

00:03:00
fluently.

00:03:00
At that point I had a lot of kind of exposure to a lot of

00:03:03
languages and in Finland at that time in the early 90s, when I

00:03:08
was going through school, linux had just been created, actually

00:03:12
not at my school but at the school right across town and so

00:03:15
a lot of our labs were running on Linux.

00:03:17
So I had good exposure to some of these kind of new operating

00:03:20
systems and things that were coming out.

00:03:22
So this intersection of computer science and linguistics

00:03:26
was like perfect for me in a way.

00:03:28
But when I say I failed into security, it's because I thought

00:03:31
I would actually end up being a programmer but turns out I suck

00:03:34
at coding and so I went through , got my degree, got a job with

00:03:40
a company doing translation software or software designed to

00:03:44
help human translators.

00:03:46
So again, it's like the perfect convergence of all the things

00:03:49
in my background.

00:03:50
That would make it good.

00:03:51
But I wasn't good enough to program on our own software and

00:03:55
the company was growing really fast at the time.

00:03:58
So they came to me and they said hey, look, you're not going

00:04:01
to cut it in the software development team, but we've got

00:04:03
real big needs on IT infrastructure because of all

00:04:07
the growth that we're having.

00:04:08
We're opening new offices in a bunch of countries.

00:04:10
You know.

00:04:10
We've got a lot of network capacity that we need to expand.

00:04:13
We're going through an IT professionalization kind of

00:04:16
process things.

00:04:18
Everything on the IT side had been done very shoestring up to

00:04:20
that point.

00:04:21
You know this is in the days when we would have had a file

00:04:24
server.

00:04:24
That was just a tower sitting under somebody's desk right, and

00:04:28
so we were going from that into actually having server rooms

00:04:31
and, you know, having raised floor for the first time and you

00:04:34
know some of these terms go over our audience's head, who's

00:04:36
all born in the cloud, and they're like what is raised

00:04:38
floor?

00:04:39
I get it, but you know that's how I got into IT in general and

00:04:44
we didn't really have a strong distinction between IT and

00:04:46
security in those days.

00:04:47
It was all just, you know, one team, you took care of

00:04:49
everything.

00:04:50
We did everything from installing drivers and standard,

00:04:54
you know, laptop and desktop setup to install antivirus,

00:04:59
patch operating systems, run boot scripts that forced updates

00:05:03
to operating systems so people couldn't fall too far behind.

00:05:06
All that kind of stuff fell into, you know, into my domain

00:05:10
and I stayed with that company for seven years, kind of worked

00:05:13
my way up through the ranks of IT and security.

00:05:17
Had, by the way, like the two biggest breaches of my career,

00:05:21
both at that company.

00:05:21
Happy to talk about both of those.

00:05:23
I think the statute of limitations for staying quiet on

00:05:26
them has well passed by this point.

00:05:28
But some fun lessons learned out of that, and you know, and I

00:05:33
kind of stayed in IT and insecurity as a practitioner for

00:05:36
the next well, 13 years in total at the first half of my

00:05:41
career and then kind of transitioned over more onto the

00:05:44
vendor side.

00:05:44
So not a typical journey, I would say, but I really learned

00:05:49
a lot over the over that 25ish years that I've been working in

00:05:54
IT.

00:05:56
Speaker 1: So, with you know, a background of all that travel,

00:06:02
speaking different languages and whatnot, was there ever a pull

00:06:06
to go into any of the federal agencies or anything like that?

00:06:10
I would think that that would be a skill set that would be

00:06:15
extremely tempting for them.

00:06:18
You know, and at least from my own experience, right Like I

00:06:21
tried to go into federal law enforcement out of college, and

00:06:26
I mean they could have sent me anywhere.

00:06:29
Right, like I could have signed up with any of the agencies and

00:06:32
they sent me anywhere.

00:06:33
Right, I would have been cool with it, it would have been fun,

00:06:35
it would have been the perfect time to do it.

00:06:37
Was there ever that kind of temptation or curiosity on your

00:06:42
end For sure.

00:06:43
Speaker 2: Have you ever seen the movie Spies?

00:06:44
Like Us, I don't think I have.

00:06:47
It's great.

00:06:48
It's from the 80s Chevy Chase, Dan Aykroyd, one of the scenes

00:06:53
in there.

00:06:53
They're taking what's called the Foreign Service Exam and

00:06:57
that's the process through which you kind of apply to become a

00:07:01
State Department representative.

00:07:03
I have twice taken that exam, twice passed it twice, made it

00:07:07
all the way through to the final stage of interviews, and both

00:07:11
times failed out on that final stage, for different reasons,

00:07:15
you know, once when I was 22 and once when I was 36-ish, and

00:07:20
very different reasons.

00:07:21
I was at very different levels of maturity, but both times I'm

00:07:25
glad that it didn't work out.

00:07:27
There's a number of other reasons, you know.

00:07:29
I think my career on that side would have been limited anyway

00:07:32
because I am a dual national and so I think I would have been

00:07:35
somewhat limited in how far I could have gotten clearances and

00:07:38
all that good stuff.

00:07:38
But certainly there was a pull in that direction Joe and I did

00:07:42
explore.

00:07:42
It didn't work out and that's just the path that I ended up

00:07:47
going down.

00:07:49
Speaker 1: Yeah, it's really interesting.

00:07:50
You know it's weird how stressful those interviews and

00:07:55
that whole process can be, and it's like it's stressful in ways

00:08:00
that you wouldn't even expect.

00:08:02
You know, like there was, I think, the I believe the NDA on

00:08:10
this one was up a few years ago, right, but I was interviewing

00:08:13
for the Secret Service and that won the physical test was like

00:08:18
the hardest physical test I've ever been put through in my

00:08:21
entire life.

00:08:21
That was crazy.

00:08:24
You know, 15 minutes into it you're gas and it's a two hour

00:08:28
test, right, oh my gosh, it's insane.

00:08:33
But the interview part is the part that I struggled with.

00:08:36
It was asking, you know, random , seemingly random questions

00:08:42
that would fall under that type A personality that they're

00:08:45
looking for and you trying to recall it under situations where

00:08:51
you know they just read the question and you have to answer,

00:08:53
right, they're not giving you any clarifying answers or

00:08:56
anything like that.

00:08:57
They can repeat the question and while you're talking they're

00:09:01
writing down every single word that you say, right, so that's a

00:09:05
whole stress factor right there .

00:09:07
And then they're not even reacting to your answer not

00:09:11
nodding, not smiling, not nothing.

00:09:14
And so it's like I don't know what is going on here.

00:09:18
For someone fresh out of college, like myself, to go

00:09:22
through that process.

00:09:23
It was like all these other interviews, like it's going to

00:09:25
be easier than this for the normal private sector, right?

00:09:30
Like it's a crazy experience.

00:09:35
Speaker 2: I mean both times.

00:09:36
The final stage of the State Department process is a full day

00:09:41
role play scenario on site and you're thrust into a bunch of

00:09:48
different situations, which, on the one hand, is fine for me I

00:09:52
did improv comedy for a number of years.

00:09:53
I'm very comfortable getting thrown into random situations,

00:09:57
no issues at all.

00:09:58
But, to your point, you don't understand or you don't know

00:10:02
what you're being graded against and you're getting almost no

00:10:06
feedback along the way.

00:10:07
And I just think about day to day meetings that you and I sit

00:10:11
in, whether it's in person or Zoom.

00:10:14
You've at least got some kind of visual feedback coming from

00:10:18
the other side.

00:10:19
As we're talking, I can see you nodding your head.

00:10:21
I know you're listening, you're paying attention, but zero from

00:10:25
the evaluators in these contexts.

00:10:27
All you get at the end of this full day is kind of a yes or no

00:10:31
and maybe like two to three sentences of why it didn't work

00:10:34
out if it didn't.

00:10:34
Interviewing, I think, is still one of the things that we don't

00:10:38
do well.

00:10:39
By the way, also true in security.

00:10:41
I don't think we're great at interviewing and I don't think

00:10:44
we're great at giving people the opportunity to break into

00:10:48
security.

00:10:52
Speaker 1: Yeah, that was probably my biggest hurdle with

00:10:59
getting a break into security just getting a chance from

00:11:02
someone.

00:11:03
It literally took me almost three years to get into security

00:11:07
, and that's with me getting certifications, starting a

00:11:10
master's, owning all of security at my current company.

00:11:15
But I didn't have a security title and so people looked at me

00:11:19
differently, didn't give me the chance or anything like that.

00:11:21
And I just remember one of the most frustrating parts was

00:11:28
someone said I didn't get the job and I asked I said hey, why

00:11:31
didn't I get the job?

00:11:32
What can I improve on?

00:11:33
What did I do bad or what do I need to do differently to get a

00:11:37
job next time?

00:11:37
And they said, well, you didn't have any experience with Splunk

00:11:41
At this time.

00:11:43
I worked for a very small company like 30 people.

00:11:45
There was no way we were ever going to get Splunk and there

00:11:49
was no way that I was ever going to have a chance at affording

00:11:54
30 seconds of a Splunk instance in my whole lab.

00:12:00
And so it's like you're in an impossible situation.

00:12:03
You're grading me against an impossible scenario that

00:12:05
literally will never exist.

00:12:07
Why wouldn't you take someone that's willing to learn, eager

00:12:11
to learn, maybe knows a few things, has experience on help

00:12:14
desk, and train them up, rather than just saying, oh, they don't

00:12:18
know this industry-wide tool.

00:12:20
Speaker 2: Yeah, and that's crazy because in that scenario

00:12:24
in particular, whether you know a particular tool or not, I

00:12:29
think is the least important thing in somebody's application

00:12:34
for a position.

00:12:35
If I think about the priority list of things that I think are

00:12:40
important in hiring a security person, number one is just the

00:12:43
frame of mind that you bring to the question about how you

00:12:47
address security.

00:12:47
So if you're thinking about joining a new organization, do

00:12:52
you think about it on a point-to-point or point-by-point

00:12:55
basis, or do you think of a threat model and kind of

00:12:58
prioritization?

00:12:59
Because security is one of those things that is truly never

00:13:02
done.

00:13:02
Every single day, something will change within the

00:13:07
organization that needs to be thought about, reassessed.

00:13:10
Maybe it's just the volume of transactions, maybe it's a new

00:13:13
employee, somebody coming or going.

00:13:14
Whatever it may be, it may be a change in a cloud environment.

00:13:18
I mean, all of these things are happening on a daily basis and

00:13:23
so you are never done.

00:13:24
But the point is, do you come in and all you're going to do is

00:13:29
focus on one tool that you know ?

00:13:31
No, you should really have a more strategic view on

00:13:35
approaching security in an organization.

00:13:37
Maybe you start with the threat modeling, maybe you start with

00:13:41
a framework of security evaluation.

00:13:45
There's always questions of prioritizations and trade-offs,

00:13:47
because ultimately and I know this is a little bit of a cliche

00:13:51
security is a risk management thing.

00:13:53
The most secure organization is the organization that does

00:13:57
nothing right, generates no data , processes no data, has no data

00:14:01
right.

00:14:01
But that's just not the reality .

00:14:03
You always have to work with data and with people, and so

00:14:07
it's always just a question of what trade-offs you want to make

00:14:09
, and so you need to think about that.

00:14:10
And the second thing in my mind is the creativity and the

00:14:14
troubleshooting capabilities.

00:14:15
So, to your point, your experience doing help desk I'm

00:14:20
sure you had a number of times when somebody came and was like,

00:14:23
hey, it doesn't work, gives you the least useful information

00:14:29
that they can give you, and then it's your job to figure out why

00:14:32
.

00:14:32
And you end up going through this troubleshooting exercise of

00:14:36
eliminating possible causes.

00:14:38
I actually think security has a lot of that as well, and when

00:14:42
you've checked everything, then you just need to think more

00:14:45
creatively.

00:14:45
What else could it be?

00:14:46
And, by the way, we all know most of the time it's a lot of

00:14:50
the basics it's DNS, it's update to the latest patch version,

00:14:54
whatever it's, reboot the machine.

00:14:56
We all know that from experience over time.

00:14:59
But yeah, I don't know.

00:15:01
I don't think the fact that you do or don't know a tool should

00:15:05
ever qualify you or disqualify you from a job.

00:15:08
Speaker 1: Yeah, yeah, I definitely agree.

00:15:10
So you mentioned a couple breaches.

00:15:14
Why don't we talk about the breaches?

00:15:17
Maybe if you could talk about where you were, what they were,

00:15:21
how it happened and what that environment was like, because I

00:15:25
feel like this is a known thing slash risk with security, and

00:15:33
very few people actually go through a very legitimate breach

00:15:37
, and so it's difficult to imagine it, it's hard to go

00:15:43
through to know what to do.

00:15:44
Even it can be very stressful.

00:15:46
It's kind of like a fog of war almost, and so I think hearing

00:15:50
that would be very helpful to someone out there, especially

00:15:53
myself.

00:15:54
Speaker 2: Yeah, so I've had three in my career, two that

00:15:58
were kind of larger than the others.

00:15:59
The one that was the smallest is probably the easiest one to

00:16:03
talk about.

00:16:04
It was an internal wiki that, through one network

00:16:07
configuration change, got made external, and it got picked up

00:16:11
very quickly.

00:16:12
We were doing a lot of social media marketing at the time,

00:16:15
trying to work with bloggers and so on, and there was some stuff

00:16:19
on our wiki that didn't paint the bloggers in the best light,

00:16:25
that got out there and got copy pasted and screen shot it and

00:16:29
posted on other bloggers sites and so on.

00:16:32
It was certainly a black eye to the organization.

00:16:35
Thankfully, nothing beyond the marketing side and some customer

00:16:40
support documentation got shared externally.

00:16:43
We were able to dodge the bullet.

00:16:46
The reputational damage, though, was pretty tough to deal with,

00:16:50
and certainly the possibility of working with some of those

00:16:55
bloggers on, let's say, like content placement or content

00:16:57
syndication.

00:16:58
That was all gone.

00:16:59
That ship had sailed.

00:17:01
There was no chance that these people were ever going to

00:17:04
consider working with us after that point, and that took some

00:17:07
time to repair and certainly forced the marketing team to go

00:17:12
okay, what's plan B?

00:17:13
What are we gonna work on next?

00:17:15
And it does show you that this was kind of one of the first

00:17:18
kind of virtualized environments that I worked in, so this was a

00:17:22
lot of open source software.

00:17:24
We were using Media Wiki at the time for the internal

00:17:26
documentation, the same platform that Wikipedia is built on.

00:17:29
Decent open source package has its own set of issues, as many

00:17:34
of those large scale kind of public facing things, especially

00:17:37
ones built in PHP, do.

00:17:39
We had relatively good practices around the Wiki itself

00:17:43
and so there was nothing on Media Wiki itself that was a

00:17:46
problem.

00:17:46
It was really just our network configuration that caused this

00:17:49
exposure.

00:17:50
So one of those things is, whenever you consider a network

00:17:55
change, what are the implications?

00:17:58
And I think a lot of people don't have the awareness.

00:18:03
A lot of organizations that I go talk to.

00:18:05
If you ask somebody the question what happens if I

00:18:07
change this one firewall rule or this one IP address or this one

00:18:12
load balancer, pointing from which instances to which

00:18:15
instances, like what's gonna change, what would then become

00:18:19
exposed?

00:18:19
I still think a lot of people don't have that visibility.

00:18:22
That is something that I think a lot of security teams struggle

00:18:26
with.

00:18:26
The other two were worse.

00:18:29
They were at that first company that I joined, where I worked

00:18:35
my way up through IT.

00:18:38
This is again kind of the late 90s, early 2000s time frame.

00:18:42
One of the things that we ended up having to build for our

00:18:45
customer support organization was an anonymous FTP upload

00:18:51
server.

00:18:51
So we had customers working on very large documents, probably

00:18:57
dating myself a little bit.

00:18:58
But there were desktop publishing software packages,

00:19:02
mostly from Adobe.

00:19:02
I think none of them exist anymore, but you might hear of

00:19:07
like page maker, frame maker I think InDesign is the new tool

00:19:12
that's replaced all of that kind of stuff.

00:19:14
Quarkxpress was another product in that same category, or then

00:19:18
sometimes they were just like really large word files and back

00:19:21
in those days most email clients couldn't do anything

00:19:25
more than maybe a three to five megabyte attachment and we very

00:19:30
often had customers that had documents that were well into

00:19:32
the hundreds of megabytes.

00:19:34
They would have problems using our software with those

00:19:37
documents and they would need to upload those documents to our

00:19:40
customer support team.

00:19:42
So we had an old server that wasn't really used for any other

00:19:47
purposes and we said, hey, this will be great, it's got

00:19:50
reasonably large raid on it.

00:19:53
We've got about 25 gigs of disk space on it that are completely

00:19:57
unused.

00:19:58
Again, 25 gigs was big back then, by the way.

00:20:01
So we set up this server to be an anonymous FTP server so you

00:20:07
could connect an FTP client.

00:20:10
You would not get a directory listing, so you couldn't see any

00:20:13
of the files.

00:20:14
You couldn't download anything.

00:20:16
If you tried to list or download, you would just get an

00:20:19
error message.

00:20:19
But if you tried to just put a file that worked and that was by

00:20:23
design and so then you would submit, you as a customer would

00:20:26
submit your support case and then give your file name.

00:20:30
Now the fact that it was an old server is actually where one of

00:20:36
our biggest problems started.

00:20:37
So it didn't support Windows NT4.

00:20:39
So we were still running NT3.5, I want to say or 3.

00:20:43
Can't remember what version.

00:20:45
Everything was 8.3 nomenclature , meaning file names, max8

00:20:52
characters, extension, max3 characters.

00:20:55
What ended up happening was there was this vulnerability in

00:21:01
that Windows version where if you created a folder that let's

00:21:07
call the folder dash so just the hyphen symbol and then you

00:21:11
create a subfolder of dash called double dash and you

00:21:15
create a subfolder of that called triple dash, well, once

00:21:19
you go down and you surpass 256 characters in total path length,

00:21:24
none of the permissions work anymore.

00:21:26
So it completely broke the Windows permission structure.

00:21:33
So some people knew of this.

00:21:35
We obviously didn't.

00:21:36
So what did they do?

00:21:37
They uploaded a few gigabytes of pornography, shared the links

00:21:42
and, because it was so deeply down this path structure, the

00:21:47
download permissions that we had prohibited were all of a sudden

00:21:51
available.

00:21:51
Now, we got notified of this when we got our bandwidth bill

00:21:55
from our co-location provider at the end of the month.

00:21:58
And for an organization that averaged roughly like four

00:22:02
gigabytes of bandwidth utilization at that site, all of

00:22:05
a sudden we were in the 200 range and thankfully we were

00:22:10
able to show them hey, it was this breach event and thankfully

00:22:14
they didn't steal data from us, but they did abuse our systems

00:22:18
to distribute illegal content.

00:22:20
What can we do here?

00:22:24
And they gave us a break on that.

00:22:27
But it's one of those things that to me, that actually showed

00:22:30
me that we were doing a terrible job of monitoring our

00:22:33
own systems.

00:22:34
So we didn't have anything in place to check bandwidth

00:22:39
utilization on a regular basis or even to really monitor the

00:22:44
disk drive space.

00:22:45
It didn't fill the disk, but it certainly used a huge chunk of

00:22:50
the disk and we weren't monitoring that actively at the

00:22:52
time.

00:22:52
So it's a little bit of a live and learn lesson.

00:22:54
So some of these basics that you need to think about, even

00:22:58
just checking in.

00:23:00
If you're using servers as servers, as long-lived servers

00:23:03
and not ephemeral instances, you do need to check in, you do

00:23:07
need to put these monitoring tools in place.

00:23:09
And so, yeah, those are two of the big ones.

00:23:11
The third one was nothing really major, just usual email virus

00:23:17
Did send some documents from people's inboxes.

00:23:19
People may have heard of the Melissa virus or the I Love you

00:23:24
virus from those days.

00:23:25
We got hit with a couple of those and most of them just

00:23:27
created huge volumes of email traffic.

00:23:30
Some of them would send documents from your send folder.

00:23:33
They would forward them outside .

00:23:35
Nothing huge there, thankfully, a few documents that went out,

00:23:40
but mostly just clogged up our mail servers for a few days and

00:23:44
that virus would then flare up again from time to time.

00:23:47
Somebody would come back from vacation, see it in their inbox

00:23:51
and double-click the document with the word macro.

00:23:54
That kicked the whole thing off again.

00:23:55
So it took a while.

00:23:57
We ended up having to go into the exchange server and go into

00:24:00
people's mailboxes one by one across the organization and make

00:24:04
sure that there were no copies in anybody's email anywhere.

00:24:07
Yeah, those are some of my fun stories.

00:24:13
Speaker 1: Yeah, the only breach experience that I have actually

00:24:17
and it wasn't even my environment being breached when

00:24:21
I was working at a credit bureau , equifax happened and obviously

00:24:28
I wasn't working for Equifax, I was at a different place but

00:24:35
there was so much fear in the space that we literally got a

00:24:39
blank check for the first time ever from the CEO just saying

00:24:45
whatever you need, just get it.

00:24:47
If you need to hire more people , you can do it.

00:24:49
Our team size quadrupled almost overnight.

00:24:54
Within the next few months.

00:24:56
We were hiring several people and in security that's unheard

00:25:00
of.

00:25:00
That is something that you do not expect.

00:25:04
That is extremely difficult to pull off, even just hiring those

00:25:08
people, and that was a really interesting time.

00:25:14
There was a lot of fear around it and, to give credit where

00:25:21
it's due, the security team knew that and we knew that we had to

00:25:25
use that opportunity as the opportunity to get some of the

00:25:30
tools that we've been trying to get, to get the headcount that

00:25:33
we've been trying to get, and I remember one of the architects

00:25:39
was discussing how much money the breach actually cost Equifax

00:25:47
and the number that they could come up with.

00:25:50
The dollar amount right was in the billions, something like

00:25:54
that, but the damage to the brand itself was almost

00:25:59
incalculable, because now I bring up Equifax and everyone

00:26:05
remembers that breach it was on morning news telling people go

00:26:10
lock your credit reports and everything else right, because

00:26:13
they have all this data.

00:26:14
There's nothing we can do about it.

00:26:16
They just have it and they sell it and they reuse it.

00:26:18
It really almost opened Pandora's box to the credit

00:26:23
bureaus in a way that people didn't really notice.

00:26:27
They didn't even know about it or think about it beforehand.

00:26:31
So it was a very interesting time for sure.

00:26:35
Yeah.

00:26:37
Speaker 2: And I'm curious to your experience going through

00:26:39
that.

00:26:40
When you kind of got this blank checkbook, what did you do

00:26:44
first?

00:26:47
Speaker 1: Yeah, I think what we did first was we actually

00:26:50
bought two different technologies for the IEM team,

00:26:55
which was sold in a way that like, hey, if Equifax had these,

00:27:00
the breach would have been impossible, Right.

00:27:03
So that was like a no-brainer for the organization to do.

00:27:06
And then we built teams of 12 or more people around these

00:27:13
tools to run them for the entire organization, which was

00:27:19
challenging, right, Because then you're questioning the talent

00:27:23
that you're actually hiring, the people that you're bringing in,

00:27:26
how you're bringing them in and all this stuff.

00:27:29
And then we ran into challenges where we had more interns or

00:27:36
people fresh out of college that we had people that were

00:27:39
actually two to three years in IT overall.

00:27:42
I think at one point I was the only person on the team that had

00:27:47
prior IT experience, and so when you build a team like that

00:27:51
in security, I mean it's different, right.

00:27:55
You're restricted with what you can actually do, what you can

00:27:57
accomplish and pull off and whatnot.

00:28:00
Speaker 2: Yeah, that's interesting.

00:28:02
I'm curious, then you know, to follow up on that.

00:28:06
So you bought this IEM tool that was sold as if you had this

00:28:11
.

00:28:11
That couldn't have happened.

00:28:12
But after you implemented it, did you have that same

00:28:17
conclusion.

00:28:17
Did you believe that that was true?

00:28:23
Speaker 1: So I understood where they were coming from and you

00:28:27
know they weren't the only solution on the market, that's

00:28:30
for sure.

00:28:31
If their solution was working you know, 100% of the time, the

00:28:38
way that they claimed it would be working then then, yeah, it

00:28:43
would have been the right tool for the environment and it would

00:28:47
have done what they wanted it to do and things like that.

00:28:50
But you know, to be quite honest, the solution that we

00:28:54
bought, due to, you know, external circumstances, right,

00:29:00
it was just the wrong solution for the environment.

00:29:03
And so you know, there was key people in my org that, basically

00:29:08
, you know, hitched their horses to this wagon and they were

00:29:12
going to.

00:29:12
They were either going to succeed or they were going to

00:29:14
die with it.

00:29:15
And they ended up, you know, not actually dying with it, but

00:29:18
they died with it, you know, and it created a lot of issues, a

00:29:24
lot of heartburn, you know, for basically everyone in the org.

00:29:28
Speaker 2: I've been on the vendor side of security software

00:29:29
for about seven, eight years now and the thing there's a

00:29:36
couple things in what you said that really kind of stick with

00:29:40
me, and I think anybody who says that their solution is

00:29:45
bulletproof or is the silver bullet to solving this and

00:29:50
preventing the next one and so on, is like if anybody who hears

00:29:55
that should know that that's marketing, speak right and to

00:30:00
your point.

00:30:01
It may be the right solution or it may be the right category of

00:30:05
solution, but if it requires that you change the way that

00:30:09
your organization works in order to use it, I think its chances

00:30:14
of success are very low within your organization.

00:30:17
I just don't see a lot of the customers that I've worked with

00:30:21
over the years saying, well, you tell me how to run security or

00:30:26
how to run cloud over here at you know, insert corporation

00:30:30
name, right and I just don't think that's realistic.

00:30:33
You know, when I joined a cloud security posture management

00:30:35
company in 2016, and we were in the very early days of cloud

00:30:39
security posture management, right and there was this big

00:30:42
debate going on about what's the right approach quote unquote

00:30:45
right approach to cloud security .

00:30:47
Is it CSPM, which by nature, is kind of a let's observe what

00:30:53
you're doing.

00:30:54
We'll just kind of watch what you're doing, gather that up and

00:30:57
then show that picture back to you with an assessment of what's

00:31:01
good and bad as either defined by whatever number of standards,

00:31:06
like this cybersecurity framework, cis, benchmark,

00:31:09
whatever, or some rules that you yourself define.

00:31:12
Or is it this CASB approach?

00:31:15
Right?

00:31:15
Casb was a very hot topic at the time.

00:31:18
You know, cloud access security broker, where you're only going

00:31:22
to use the cloud in a way that this CASB tells you is okay.

00:31:26
So some security team in theory would come along and define

00:31:31
like, oh okay, you know, joe, he's with the development team

00:31:34
and they have access to this, this, this, this, this here's a

00:31:38
set of rules for what they can and cannot do.

00:31:40
We're going to translate those rules into, like AWS, iam

00:31:43
policies or VPC constraints or what have you right, and as long

00:31:48
as you kind of color within those lines, you're fine and so

00:31:52
it's.

00:31:52
You know, does your organization continue to run and

00:31:55
were they are observing it?

00:31:56
Cspm approach or do you take this thing that prescribes to

00:32:01
you how is you know what good cloud usage is and you change

00:32:05
everybody's workflow to adapt to that and I can tell you, like

00:32:08
in those days what we observe time and time again not to cast

00:32:13
aspersions on CASB vendors out there, but no company was going

00:32:17
to change their operating model in order to accommodate this

00:32:20
cloud.

00:32:20
It just was not going to happen .

00:32:24
Why people have day jobs, they have stuff that they're trying

00:32:27
to get done and nobody's day job is to change the way that

00:32:30
they're working in order to onboard this new vendor offering

00:32:34
.

00:32:34
Like nobody's even in the security department that bought

00:32:38
the thing.

00:32:38
That's not really anybody's job description, except maybe one

00:32:42
or two people who are on that project team.

00:32:44
So I feel like there's a common problem that we have as a

00:32:49
security industry that we try to sell a solution to everybody

00:32:53
and anybody who will buy it, regardless of whether they're

00:32:56
actually the right fit or whether they're going to get

00:32:59
benefit out of it.

00:32:59
And I can tell you, as like an early stage security company,

00:33:03
that's a dangerous temptation, because of course, we all want

00:33:07
customers and we want revenue and we want to be growing.

00:33:10
But worse than having the customer it worse than not

00:33:13
having the customer is having the customer that doesn't like

00:33:16
the tool, that goes away with a bad experience or that churns

00:33:20
after one year Because you've invested all this time and

00:33:23
energy in cultivating the relationship and getting them on

00:33:26
board, and then they're just going to walk away.

00:33:28
And you know, maybe you've educated them on a new space

00:33:32
like API security, like we're doing, but then they didn't like

00:33:35
your approach because your approach required them to change

00:33:37
and so they're just going to go to some other API security

00:33:40
vendor who doesn't even have to really pay much to acquire the

00:33:43
customer, because you've educated them on the market,

00:33:46
you've educated them on the attack surface and the problems

00:33:48
and so on.

00:33:49
So I just feel like that's a bad temptation and a bad

00:33:54
behavior that we as a vendor community have.

00:33:57
Speaker 1: Hmm, yeah, that is definitely something that I have

00:34:01
experienced personally, so is that experience what you would

00:34:09
say led you down the path of starting Firetail?

00:34:13
Let's talk about the tech a little bit, maybe why you got

00:34:19
involved with the company and what brought you down this path.

00:34:23
Speaker 2: Actually, what brought me down this path was my

00:34:25
experience doing Cloud Security , so a little bit less those

00:34:29
kind of vendor things.

00:34:30
I learned those lessons along the way.

00:34:31
But the previous company, divi Cloud we were that early stage

00:34:35
CSPM company.

00:34:36
We grew very rapidly for a four-year period before being

00:34:41
acquired.

00:34:42
Partway along that journey I started working with some of our

00:34:46
larger customers digital natives, global organizations

00:34:51
and you started to observe how they were changing the way that

00:34:53
they use Cloud.

00:34:56
So now every year we go to re-invent or whatever Cloud

00:35:00
conference you're going to go to and you hear from the CTOs and

00:35:04
the CIOs about how they've really changed the way that

00:35:07
they're operating their IT environments.

00:35:09
The consistent things that you hear are like we're moving away

00:35:13
from long-lived servers.

00:35:14
We're doing cattle, not pets model.

00:35:18
You'll hear that pets versus cattle analogy a lot in the

00:35:22
Cloud space in general.

00:35:23
Really, what it comes down to is like a virtual machine on a

00:35:28
Cloud network is not a server and you shouldn't treat it like

00:35:31
a server.

00:35:31
What is it?

00:35:32
It's a temporary computing node that provides CPU memory, maybe

00:35:37
a little bit of disk access in order to process a workload, but

00:35:41
it should be ephemeral and it should be treated as ephemeral.

00:35:44
We really started to see that behavior from a lot of our

00:35:47
large-scale customers, especially, again, those Cloud

00:35:50
native customers.

00:35:50
We'd ask them like and I'm much more familiar with AWS and the

00:35:55
other Cloud providers, so excuse me for just using their lingo

00:35:57
but we'd ask them what are you running on EC2?

00:36:00
They're like as little as possible.

00:36:01
In fact, we want to get everything off of EC2.

00:36:04
You say, well, what are you going to do instead?

00:36:06
Containers and serverless.

00:36:08
Why?

00:36:08
Easier to be ephemeral, lighter compute load.

00:36:12
We can actually cycle things in and out much more quickly.

00:36:16
Guess what?

00:36:17
I don't have an operating system that I have to maintain.

00:36:20
I don't need to install agents.

00:36:22
I don't need to install an EDR agent or a management agent or

00:36:25
an APM or any of that stuff.

00:36:27
I'm just going to run my workloads on Lambda because,

00:36:30
guess what?

00:36:30
The vast majority of them fire up, run for 15 seconds, then

00:36:33
wind down.

00:36:34
That's how I should be using Cloud.

00:36:36
That is the dream and the vision that Werner Fogels and

00:36:39
everybody else tells me about every year.

00:36:43
When we started seeing that shift, one of the things that I

00:36:47
realized in my conversations with some of them was that's

00:36:51
going to dramatically change the architecture.

00:36:52
If it changes the architecture, what are the implications?

00:36:55
What becomes the target?

00:36:57
It moves away from being that EC2 instance and then it becomes

00:37:02
an API sitting on a network.

00:37:03
Whether you're running Lambda, whether you're running Fargate,

00:37:08
eks, ecs, I don't care, you're going to have an API somewhere.

00:37:12
Chances are very high that API is going to be in front of a

00:37:16
dataset, in front of a set of business functions, or both.

00:37:20
That becomes your attack surface.

00:37:23
That's what started me thinking about API security.

00:37:26
I started thinking about this problem a ways back and started

00:37:29
working on it after I left Rapid 7, the company that acquired us

00:37:33
.

00:37:33
That's really the journey.

00:37:37
When we started Firetail my co-founder and I we actually

00:37:40
started by not having a piece of technology that we then wanted

00:37:45
to build around, but we actually started by doing root cause

00:37:48
analysis on all of the publicly disclosed API data breaches that

00:37:51
we could find.

00:37:52
There weren't that many at the time.

00:37:54
We've now consolidated them all .

00:37:56
If you look on our website, firetailio, and the footer,

00:37:59
you'll find an API data breach tracker, we call it, where we've

00:38:03
put together a list of all of the ones we could find.

00:38:06
There's been 40, 50 of them large-scale over the past 10

00:38:10
years that have been publicly disclosed probably far more than

00:38:13
that that have not been disclosed.

00:38:14
That tends to be the case.

00:38:17
What we realized was that the problem has actually not only

00:38:21
has the attack surface moved, but the problem has also moved.

00:38:25
It's become less a problem of, let's say, accidental data

00:38:28
exposure, which is still one of the main problems on Cloud

00:38:31
environments, and it becomes an application logic problem.

00:38:34
It becomes things like abuse of poor authentication mechanisms

00:38:38
or lack of, let's say, follow-up call authorization.

00:38:42
I authorized you once, but then I assume that anything you

00:38:45
request after that, any of your subsequent API requests, are

00:38:48
also authorized.

00:38:49
Very bad practice.

00:38:50
You need to authorize every single call, but we saw things

00:38:54
like that time and again.

00:38:55
We actually started from that standpoint and we built out tech

00:38:58
to match that.

00:39:00
Then we followed requests from customers to continue to evolve

00:39:04
what we're doing.

00:39:05
We actually ended up adding a completely new set of features

00:39:09
and functionality based on some of our early beta customer

00:39:12
feedback.

00:39:12
That's been a great learning journey for us, but yeah, that's

00:39:16
how we got started.

00:39:17
Speaker 1: Hmm, that's interesting.

00:39:20
Moving to containerized environments, I mean it's

00:39:28
difficult.

00:39:29
I feel like it's easier said than done and a lot of companies

00:39:35
or people don't quite understand the work that goes

00:39:38
behind that, Because as soon as you throw an agent on there,

00:39:44
you're eating up more utilization and you're spending

00:39:47
more money on the solution than you would have been.

00:39:50
It's a considerable amount too.

00:39:52
Throwing an agent on something, to secure it or gain insight is

00:39:59
a legacy process.

00:40:01
It's a legacy solution.

00:40:03
The industry as a whole is having to learn new ways of how

00:40:10
to actually gain insight into these ephemeral workloads.

00:40:15
Speaker 2: It's difficult for sure, yeah, For sure.

00:40:19
I think to that point, Joe, you'll find people shifting a

00:40:24
lot of their security efforts away from, let's say, the

00:40:27
runtime monitoring that you might get from an agent into

00:40:31
secure build.

00:40:32
What all is in my pipeline?

00:40:35
Have I done code scanning?

00:40:37
Have I checked my third-party dependencies?

00:40:40
What about all these third-party containers that I'm

00:40:43
including to build my workload?

00:40:44
Maybe I'm grabbing Nginx as a reverse proxy?

00:40:47
Am I grabbing the right version ?

00:40:50
Is it the most secure version?

00:40:51
Is it the compatible version?

00:40:53
All of those types of questions .

00:40:55
They almost become more of a to use the buzzword, Sbom type of

00:41:00
problem than they do a runtime problem.

00:41:04
Especially if they are more ephemeral workloads that aren't

00:41:07
going to be out there, or where you've got a lot of code updates

00:41:10
that are pushing new versions very regularly, the secure build

00:41:14
aspect becomes maybe more important than the secure

00:41:17
runtime aspect.

00:41:18
But that is a challenge and that is not something that a lot

00:41:21
of security teams do, especially because who owns the

00:41:25
build process?

00:41:26
It's often not security.

00:41:28
In fact, 99% of the time it's not security, it's developers.

00:41:32
I don't know how it is where you work, but I've certainly

00:41:36
observed my share of organizations where security and

00:41:38
developers don't always see eye-to-eye.

00:41:44
Speaker 1: Yeah, that in and of itself, I feel like you need a

00:41:48
security person that used to be a developer that converted to a

00:41:51
security team.

00:41:52
It's actually like speak their language and break down those

00:41:57
walls and barriers, because it's a difficult I mean it's a

00:42:02
difficult experience to bridge.

00:42:06
It's a difficult gap to bridge, with someone coming in and

00:42:10
saying, oh, we should restrict this in this way or do it a

00:42:14
different way, and the developers had it's like have

00:42:17
you ever been a developer before ?

00:42:18
Do you know what you're talking about?

00:42:20
Do you understand why we did it this way, something that is

00:42:25
pretty difficult for myself even and, thankfully, my current

00:42:30
employer.

00:42:30
We have an app site guy that is primarily a developer that is

00:42:35
just having a security focus, and even at my last employer,

00:42:41
the entire app stack team was former developers that you know

00:42:45
wanted to have a security focus and they created this team

00:42:48
around them.

00:42:49
I really feel like that's the only way to really do it

00:42:53
successfully, because I've I've tried it just about every other

00:42:56
way and it just doesn't work.

00:42:58
Speaker 2: Yeah, it can be really challenging and I think

00:43:00
like, thankfully you've got this app stack person in place

00:43:04
that's able to maybe kind of bridge the gap and speak the

00:43:06
language of both sides.

00:43:08
But I find that even you know, on the most basic level, a lot

00:43:12
of the times the organization is not set up for success because

00:43:15
the, let's say, the KPIs or the targets are very different.

00:43:19
You've got a development team for whom security is, at best, a

00:43:22
secondary responsibility and at worst, not even on their list

00:43:27
of responsibilities.

00:43:28
They're tasked with delivering features and they've got, maybe,

00:43:32
time pressure, they've got pressure to release, because why

00:43:36
you're in a competitive market and management says we need this

00:43:39
feature to be competitive or to be ahead of the competition or

00:43:41
whatever.

00:43:41
And they've got, you know, their bosses breathing down

00:43:45
their necks to deliver, deploy, deliver, deploy right, and

00:43:48
nowhere in that list is security .

00:43:50
And then you've got your job, which is keep the organization

00:43:54
safe, and so sometimes even just the basic kind of misalignments

00:43:58
at the organizational level I've seen can really cause a lot

00:44:01
of strife, and that's really unfortunate, because nobody

00:44:05
wants to ship insecure codes, nobody wants to open the

00:44:08
organization up to vulnerabilities.

00:44:09
But when you create these systems that don't have a

00:44:13
holistic view.

00:44:14
I think that's a pretty, you know poor management structure.

00:44:19
Speaker 1: Yeah, absolutely so.

00:44:22
Where do you, where do you envision this space going?

00:44:25
Cause it seems like you're taking this approach from a

00:44:30
different angle.

00:44:30
That I mean personally.

00:44:33
I would like to see more solutions.

00:44:34
Approach it from.

00:44:34
Where do you see it going?

00:44:39
Speaker 2: So we came to API security from cloud security,

00:44:41
and one of the other things I observed aside from, let's say,

00:44:45
the architectural changes on the cloud security side was that I

00:44:47
saw the customers that we were working with struggling to

00:44:52
implement cloud security because of any number of reasons, but

00:44:55
one of the big ones was, a lot of the times, once security

00:44:59
comes to the table, on the cloud security side, development is

00:45:02
way out ahead.

00:45:03
A number of workloads are already out there, Applications

00:45:05
are already running in production, et cetera.

00:45:07
So a lot of these customers that we would work with, let's

00:45:12
say, on a POC process or whatnot , one of the very first things

00:45:13
they would do on the cloud security side is they would say,

00:45:15
okay, great, now I have a picture of my entire cloud,

00:45:19
let's say a state.

00:45:19
Help me now slice it up and break it down into manageable

00:45:24
chunks, like application workloads, and that I saw really

00:45:26
becoming like a consistent theme.

00:45:28
So, company after company, customer after customer, we

00:45:32
would see like the first set of workloads it would be like, hey,

00:45:37
help us manage tags or help us create these structures that we

00:45:39
can then measure security against, because it's not one

00:45:42
size fits all.

00:45:42
You've got a different risk profile for different workloads

00:45:45
depending off their internal, external, what data might be in

00:45:48
them?

00:45:48
Do they have customer PII in them, all these types of

00:45:52
questions that might be in the cloud security side we change

00:45:56
the security requirements for them.

00:45:58
So what I see happening is I think it cloud security will

00:46:01
continue to go that direction, and so you know people like you

00:46:04
who work in cloud security day to day.

00:46:06
I think, whether you're there already or not, or whether

00:46:09
you're going to get there in the next couple of years, I think

00:46:11
you will get pulled down the direction of slicing your cloud

00:46:15
security practice up into manageable workloads, namely

00:46:19
applications.

00:46:21
What we've seen from the API security side is that cloud

00:46:24
security is starting to encompass everything that kind

00:46:27
of sits below the API.

00:46:30
So infrastructure layer, identity and access management,

00:46:32
operating system, especially for things like Kubernetes,

00:46:36
clusters that's all kind of part of a cloud security platform.

00:46:40
Nowadays, you talk to any of the now called CNAP vendors CSPM is

00:46:45
very last decade, right but you talk to any of the CNAP vendors

00:46:49
and they'll be able to give you all of that.

00:46:50
What they're missing is the API security piece on the top of it

00:46:54
, which is a really interesting intersection of data, business

00:46:59
logic, application functionality and external exposure, and so

00:47:03
our goal with what we're doing at Fiertail is to make kind of

00:47:09
the discovery of APIs very easy and then something that you can

00:47:12
take and integrate into a cloud security program or an

00:47:13
application security program.

00:47:14
Also make it so that you can deploy controls for some of

00:47:19
those types of or some of those top attack vectors that we've

00:47:23
observed.

00:47:23
So can we do good authentication and authorization

00:47:26
checks, can we give you good visibility into when API calls

00:47:31
aren't looking the way that they should relative to some of

00:47:33
those risk factors.

00:47:34
That's where we're trying to take it and we're trying to make

00:47:37
it a piece that is very easily consumed as part of a broader

00:47:40
kind of cloud slash, cloud app, sec program.

00:47:46
Speaker 1: Yeah, it's a very interesting take and I wish that

00:47:50
we had more time today to talk about it, but that just means

00:47:54
that I'll have to have you back on to talk about it more in

00:47:56
depth.

00:47:57
Well, jeremy, yeah, absolutely Jeremy.

00:48:01
Before I let you go, how about you tell my audience where they

00:48:06
could find you if they wanted to reach out, where they could

00:48:08
find Fiertail and all that good information if they wanted to

00:48:12
learn more?

00:48:14
Speaker 2: Yeah, the website's real easy.

00:48:15
We are just Fiertailio.

00:48:16
I am just Jeremy at Fiertailio, so very easy to get in touch

00:48:23
with me.

00:48:23
I have a Twitter handle, but I won't even share it because I

00:48:26
never use it.

00:48:27
The company has a Twitter handle which is Fiertail

00:48:30
underscoreio.

00:48:31
We're not super active on there , so I would say email is

00:48:34
probably the best way to reach out to us.

00:48:36
Last thing I'll probably mention on that side is not a

00:48:41
lot of people are super aware of API security and the risks that

00:48:44
it might pose.

00:48:45
So one of the things we've tried to do is to really

00:48:47
summarize some of that root cause work that we did at the

00:48:50
beginning of our own journey.

00:48:51
So if you go to our website now , across the top, you'll see the

00:48:55
state of APIs in 2023.

00:48:56
There's a free download report there That'll tell you some of

00:49:01
the analysis that we've done around API security breaches,

00:49:05
what went wrong in those situations, et cetera.

00:49:07
That's a great place to get started if you're looking at the

00:49:11
space.

00:49:11
Otherwise, just reach out anytime.

00:49:14
Speaker 1: Thanks, Sherry, for coming on.

00:49:15
I really appreciate our conversation, Really enjoyed it

00:49:18
and I hope everyone enjoyed this episode.