Navigating the Complexities of API Protection and Compliance

Episode Transcript
Available transcripts are automatically generated. Complete accuracy is not guaranteed.
Craig (00:00):
Cool, all right, welcome to another podcast.
We've got Blake Gray Lou and aspecial guest, Jeremy Snyder.
Please introduce yourself.

Jeremy (00:12):
Yeah, hey, happy to be here.
Thanks for having me.
My name is Jeremy Snyder.
I'm one of the two co-foundersover at a little API security
company called Firetail.
Happy to be on the show today.
Share any information that Ican about what we do or about
the challenges of the API space,or really answer any questions
you might have Awesome.

Blake (00:31):
Tell us about Firetail for those who may not be
familiar.

Jeremy (00:35):
Yeah, we are about a two year old company working in the
API security space.
As I mentioned, we're a softwarecompany.
We make about three or fourdifferent software components
that are really designed to helppeople who are making APIs
either make them more secure bydesign or secure them at runtime
, and we can get into some ofthe details around that.

(00:56):
But the kind of the shortversion of it is that we've got
like some inline components thatdevelopers can embed in their
APIs that do security checkinginline real time.
So that's what I mean when Isay like help people ship secure
APIs.
And then on the other side,we've got a set of components
that will do things likediscover APIs running on cloud
platform.

(01:16):
So if your company is runningon AWS, azure, gcp, we can help
bring continuous visibility intoAPIs new APIs that might get
launched, existing APIs thatmight get updates to them, new
functionality on them, etc.
As well as kind of monitoringall the usage and traffic around
those APIs, looking formalicious patterns, looking for
things like data leakages and soon.

(01:38):
And yeah, in a nutshell, that'swhat we do and you know happy
to go into any more detail onany of that that might be of
interest.

Craig (01:45):
So quick question that comes to mind Is it just for
really simple terms?
Is it fair to say that yoursoftware is kind of like a
security water filter forexisting APIs out there to make
you?
Know, clean it up and make itbetter.

Jeremy (02:01):
Look, it can be, but only that one component that I
mentioned, that's the embeddedcomponent.
That is sort of like a securitywater filter and to kind of
continue on that analogy, let'ssay that, like your municipal
water system has rules aroundwhat acceptable water is right.
That might be the pH level,that might be the purity level,
etc.
Most of the time whendevelopers build APIs, if

(02:24):
they're following kind of modernlet's call them development
best practices, they should bewriting something called an API
specification.
You'll often hear this referredto as a swagger file or an open
API spec OAS, and what thatdoes is it describes how the API
should function.
One of the gaps that weidentified is that you have this

(02:45):
description that says what theAPI should do, but usually
there's nothing that checkswhether that is what the API
actually does.
So our little inline componenttakes that specification and
turns it into an inline filter.
So as API traffic comes in, ourcomponent we call them the
firetail code libraries willcheck the API call that's coming

(03:06):
in.
Does it match what thespecification expects an API
call to look like?
If yes, proceed.
If no, block it and throw theappropriate error message that
corresponds to which part of itwasn't right and log that
somewhere.

Craig (03:21):
So it's almost like extended detection and response
for eight APIs.

Jeremy (03:27):
In a way and although I, like I, don't want to sound
more grandiose than we reallyare we're not yet at a point
where we're taking that data andcorrelating it with a bunch of
signals from, let's say, theoperating system layer or from
network or whatever.
So I would call it moredetection and response oriented
specifically to APIs right now.
Sure.

Blake (03:47):
Sure, tell us what an API , tell us about API
vulnerability and what thatwould look like for people that
aren't familiar with those typesof activities and threats.

Jeremy (04:00):
Yeah, and let me start by just kind of describing at a
high level how APIs usually kindof function, right.
So most people use APIs everyday.
In fact, I would wager ifyou're using the internet, you
are using APIs every day and youjust don't really realize it.
Every time you pick up yourphone and you do something like
a mobile food order or you orderride share or really social

(04:22):
networking, any social media anyof that, very little is
actually happening on the phone.
What really happens is that onthe phone, the app that you're
using packages up the thing thatyou're looking to do.
That might be Jeremy looking tolook at Blake's profile on
LinkedIn, right?
So there's a request where Isay I am Jeremy and I have some

(04:43):
piece of information thatidentifies me as Jeremy.
That could be a user ID, thatmight be a security token that
LinkedIn has provided to meafter I logged in.
And then I have the aspect thatsays like I want to look at
Blake's profile and maybeBlake's profile ID is one, two,
three, four, five, just to putit simply.
So what's really happening atthat point in time?
When I am, my LinkedIn app sayshow me, blake's profile is my.

(05:06):
The app on my phone says usethis token, send it to LinkedIn
over an API and request the userprofile one, two, three, four,
five to display right.
So that's how an API works.
Now what happens from a securityperspective is there's a couple
of things in there.
One is that some APIs can betricked into giving my token to

(05:28):
other people so that they canimpersonate me.
But more often than not, one ofthe big problems is that when I
request to look at this userprofile one, two, three, four,
five there's an authorizationcheck that happens, which is
should Jeremy be allowed to lookat Blake's profile?
In the case of, let's say,linkedin, probably the answer is
going to be a default yes.
But when you put that into,let's say, a ride sharing app

(05:54):
and I say I'm Jeremy, with thistoken, I want to view Blake's
ride history and Blake is theuser one, two, three, four, five
.
Should I be allowed to do that?
No, there's a permissions checkthat clearly says like, no,
you're not allowed to look atanother user's ride history.
But this abuse of flaws andauthorization categorically
that's the number one categoryof flaws that we see on APIs.

(06:16):
It doesn't tend to be a problemin people using mobile apps
themselves.
There might be some controlsinside the app.
There might be some interchangeof data between the app and the
back end.
That makes it all kind of clearand checks the permissions and
everything.
But when hackers abuse thoseAPIs, they don't abuse them
through the mobile apps.

(06:37):
They're going to go straight tothe API and they're going to
programmatically try tocircumvent controls on the back
end to extract data.
Does that kind of answer yourquestion and give something of a
scenario?

Blake (06:49):
Yeah, absolutely.

Craig (06:51):
So quick question comes to mind Do cybersecurity experts
, researchers, pen testers useyour product and suite to kind
of as a tool set?

Jeremy (07:02):
So mostly our product is used directly by people who are
building their own APIs.
So it's mostly softwarecompanies, mobile app companies,
iot companies, really any kindof technology firms right,
they're the ones that use ourproduct to test the security of
their own APIs, and what we givethem is we give them a view of

(07:23):
all the APIs they're running,including the ones that their
developers have created that thesecurity team didn't know about
.
We give them a picture of whatthose APIs look like to the
outside world, so like what theAPIs are exposing, let's say,
the functionality that's beingexposed, the variables that
might be passed in, etc.
And we do an analysis of thatpicture to tell them where the

(07:45):
security risks are around theAPI, so almost like a stoplight
report, something like that.
We tend to call it securityposture management, because it's
kind of this like discovery,inventory, assessment.
And, by the way, the last stepof that is that we give
recommended remediations.
We're like, hey, your API lookslike this.
You shouldn't really be usinginteger IDs, because that makes

(08:07):
your API very prone to datascraping, as an example.
That's the type of visibilityand the type of recommendations
that we give them.

Blake (08:15):
Cool.
What type of likevulnerabilities have you guys
found in your research?
I mean it sounds like there'ssome scary stuff.
I mean I'm assuming in somesoftware I know, and I mean even
like Intuit, for example youknow, I don't want to call
anybody out specifically andthat is not who we're
referencing, but they have mysocial security number or

(08:37):
business ID and they're using acall to API for whatever you
know paste banking and I meanwhat type of scary and sensitive
things have you seen beingpassed through APIs?
And I'm sure you've probablyseen some intense
vulnerabilities that maybe thesesoftware developers don't even
consider.

Jeremy (08:56):
Well, let me give you a few different things.
One is something that we see onour own APIs that we stand up
every day.
We're constantly launching APIsto test them for various
purposes test our software withit, test vulnerabilities, etc.
First of all, one of thescariest things that I think we
see, just from a kind of bigpicture perspective, is the

(09:19):
amount of automated traffichitting anything on the internet
nowadays is insane.
So we're a small company, right?
We're a two year old companyheadquartered in Northern
Virginia.
We've got, you know, 12 peoplespread across the US, ireland,
finland, etc.
We're a very small company, buteven us, with our you know

(09:39):
small company, small brand name,etc.
Our APIs that we put onlinetend to see traffic within about
three minutes, and I've talkedto other cybersecurity
researchers and experts and thisis pretty consistent Anything
you put online will get probedwithin a very, very short period
of time.

(09:59):
On the back of that, the probingis not one time drive by
probing.
It's not.
Oh, let me just see what'srunning here.
It's oh, let me see what'srunning here.
I got a response from aparticular IP address or
particular DNS name.
Let me issue some follow uprequests.
Is it running WordPress?
Is it running Drupal?
Is it running some commonsoftware that I might know about

(10:20):
?
Is it running MicrosoftExchange?
On and on to try to iterateover and discover what the tech
stack is behind it, and thentypically launching exploits
against a particular tech stackonce it's been determined.
So this is like I said, it'snot one time drive by like, oh,
just did I get a response?
Is there an active target there?

(10:41):
What is the target?
What is it running?
Is it vulnerable to theseexploits that I'm seeing and
again, you're seeing that withinminutes.
We also, along with that, wealso see probing For tokens and
secrets and passwords and so on.
So very often when you'relaunching an app, you'll have
some you know, service accountpasswords or things like that

(11:02):
that are associated with it.
Those are sometimes stored inlike config files, environment
variable files, etc.
We all we see requests lookingfor those files.
So there's that.
That's one thing that I thinkis just everybody should be
aware of, and the way I usuallytell people to think about this
is just remember, hackers havecloud and hackers have
automation too.
It costs pennies per hour torun these continuous probes of

(11:25):
what's out there on the internet.
Right, it's not expensive andit is a high value, low cost
activity for them, because whenthey do discover that one system
that is running the unpatchedversion of JetBrains or whatever
it is, boom, there's a targetthat they can actively exploit.

Craig (11:44):
So one thing that comes to mind for me is like port
scanning right.

Jeremy (11:48):
Yeah, yeah.
So what this is?

Craig (11:50):
Yeah, so it's like port scanning for the or at the API
layer.
But I guess my question is I'massuming with your platform you
can program in the API so thecustomer wants to kind of
monitor and be notified whenthose actions happen.
Yeah, but if you don't havesomething like your technology,
how what they get, how wouldthey know?

Jeremy (12:11):
The best would be if they have general network
telemetry that's running acrosstheir entire IP range so they do
know if some new service goesonline.
But that is often not the caseand especially on cloud
platforms.
A lot of organizations willkind of by default turn off that
monitoring because there's acost associated with it.
So they only turn it on oncethey know that there's an

(12:32):
approved new production servicerunning at IP address 1.2.3.4.
Yeah, let's turn on logging forthat platform once we know
about it.
So you know it can be a bigblind spot to your question,
craig.

Blake (12:45):
We play a lot in the compliant space and our last
guest we talked a lot aboutaerospace and something that we
never really considered.
I mean, obviously, becausewe're not in aerospace, but
there's no physical securitymandates around aircrafts and
there's so much technology inthese aircrafts.
So the unsexy question, butalso the question that I find

(13:09):
myself asking, is is there anycompliance mandates that are
grounding, api security?

Jeremy (13:17):
Yeah, I wish there were, and are we moving?

Blake (13:21):
towards.
That Is that we're moving.

Jeremy (13:24):
Look?
I hope so, as of yet we haveseen nothing at a national level
or at what you would think ofas an industry level, right?
So if you think of some of thetop compliance standards that
are out there, you have NISTstandards, you have things like
PCI or HIPAA that are moreindustry specific.
Currently, none of them havespecific car valves for APIs.

(13:46):
The most recent PCI, dss 4.0,started to introduce APIs as
being in scope, but with a very,very, very lightweight set of
requirements around them.
Pci is one of the fuzzier oneswhere there's a lot left to the
auditor's interpretation of aparticular rule set.
There's not a ton of superprescriptive controls, but I'm

(14:09):
glad that it got mentioned therefor the first time.
Otherwise, we do work withcustomers in other parts of the
world, so some, for instance, inSoutheast Asia, and we have
seen things like the monetaryauthority of Singapore start to
call them into question forthings around local banking
regulations.
But let's say at a global level, something like ISO standards

(14:30):
no, at a US national level, nistno.
Industry level, pci very firstintroduction of it.
I like compliance standardscoming in, whether you always
agree with the rule sets or not,whether you always agree with
the controls, and this issomething that I spent five
years working on cloud security,day to day.
Many of our customers werealways concerned with am I

(14:52):
hitting this benchmark or thiscompliance standard or this
regulatory compliancerequirement, et cetera, and they
would argue about particularthings.
I don't care if you argue ordisagree with the control.
The point to me is that itactually makes you think of that
check Right and you actually golook at this thing and what is
my configuration over here orwhat is my control over here,

(15:13):
even if at the end I'm going totell the auditor this one is not
applicable for us for reason X,you at least had to look at it
and think about the security ofthat component.
So I really hope that we're onthe path towards more API
compliance standards, but it'sbeen slow coming and, from my
perspective as somebody workingin the space, we're behind where
we need to be.

Craig (15:33):
So one of the things that comes to mind for me is quite a
concern is, like you mentionedbefore, I think that most people
are using APIs and notrealizing it.
So a really long time ago, Iused to use an app called Mint
and it would aggregate all yourbank accounts and all your stuff
.
So you're trusting thesecompanies.

(15:54):
I'm assuming, through API, thatthey're going to log in and
request and fetch the data thatyou want.
But if there's no standard,then if I get breached I'm
really the one holding the bag.

Jeremy (16:08):
Yeah, absolutely.
And I mean Mint is a perfectexample, because you're spot on
Craig the way Mint aggregatedyour bank account, credit card,
mortgage payment, all the thingsthat go into this financial
picture of Craig is APIs and thenew version of a credit karma.
They've been bugging me tomigrate as well, but the new
version of it is just going tobe the new implementation of the

(16:28):
same set of APIs, et cetera.
And you're right, and if youthink about what goes into that,
that's some very sensitive data.
If you know my credit card info, my bank account balance, that
is not data that I want any badactor to have.

Craig (16:44):
Exactly.
So I'm almost sorry, Blake, Ijust want to finish this one
thing.
So I'm almost envisioning thatthis would even be more powerful
in the UK with GDPR, because wedon't have in North America yet
an equivalent GDPR.
So I'm just wondering how thataffects your business model
there.

Jeremy (17:04):
Yeah, so funny enough.
I mean we have a lot of our R&Din Europe, in fact, pretty much
all of it.
We operate the company on GDPRstandards because when we looked
at it like hey, we're spreadbetween North America and Europe
we just found that GDPR bringsa lot of scrutiny to our own
data handling practices, evenfor us, again, as a small young
company, and we figured let'sjust do that globally and let's

(17:28):
just operate on that standard.
We're going to be betterstewards of our customer data.
As a result of following allthat guidance To your point,
there have been a lot oforganizations that have reached
out to us around just generalcustomer privacy of the data.
One of the things that we'veseen, in kind of going back to
the question about what do wesee, that's kind of scary.

(17:49):
One of the scary things we'veseen is companies having APIs
that process PII that nobodyknew about and we see instances
where an API request might lookfine but the API response is
inadvertently sending back PIIand that could be as much as
like a very common scenario thatwe see is APIs that return too

(18:15):
much data.
So I'll go back to that exampleof requesting Blake's profile.
It's very easy for a developerto write a query in the
application that says selectstar from user database, where
user equals Blake or 12345.
And instead of actually lookingat what data specifically needs
to be displayed let's say, inthe case of LinkedIn, it should

(18:37):
be just first name, last name,job title, employer they would
just give back everything Firstname, last name, job title,
employer, home address, emailaddress, phone number, et cetera
.
All this information why?
Because it's easier for thedeveloper to write a select star
query, and so identifying theseAPIs that are returning PII

(18:59):
beyond what is expected isdefinitely a very common use
case and scenario that we'veseen customers looking to solve.

Craig (19:06):
And one thing that comes to mind there.
Sorry, I don't mean to dominatethis, blake, I know you've got
another question, but one thingso, like with medical, with
HIPAA compliance, I'm surethere's APIs with EMR and EHR
systems.

Blake (19:18):
Yeah, for sure.

Craig (19:19):
At the consumer level.
All these doctors' offices wantyou to sign up for their
MyChart app or whatever.

Blake (19:24):
Yeah.

Craig (19:26):
My point is most people, I would assume, are not reading
all the fine prints, so they'relike yeah, yeah, yeah, I just
want my medical record.
My point is that wouldn't it beconsidered a breach, a data
breach, if there was some kindof API flaw or issue with the
giving exposure without theconsumer knowing?

Jeremy (19:43):
Yes, yes, it absolutely would be.

Craig (19:46):
So I think that our country needs an overhaul of
HIPAA compliance because it wasenacted in 1996 by Bill Clinton
quite old now in 2024.
But my point is I wouldadvocate for API security
standards to kind of getelevated and in cap salated into
that model.

Jeremy (20:03):
Yeah, I mean, look, you're preaching to the choir
here.

Blake (20:07):
I have this thing that's been spitting through my head
ever since you mentioned it, buteverybody knows the myth that
if you find the bottom of arainbow, you find a pot of gold
right.
And so there you are right,because that's what the API is.
Let's just be like Frank.
It sounds like it's the goldenegg of security, because

(20:27):
normally, for example, if youwanted to gain access to
somebody's bank account orcredit card information or
social security number orwhatever right, you'd have to
respectively access different,like you may have to get into
their Equifax account, or maybetheir bank account or what, but
then in this case, you just findan API that they're using and
it's all there.

(20:48):
So there you are and they'reinspired tail with essentially
like a SEAL Team 6, right.

Jeremy (20:56):
Look, I never want to promise more than we can deliver
, but certainly we're there tohelp in any way that we can,
whether it is our software,whether it is our team coming in
to help you recover from anincident that you might have or
to run an assessment of your ownAPIs.
Yeah, absolutely, it would help.

Craig (21:15):
So, going back to the HIPAA thing that we talked about
a minute ago, with the APIsecurity there, so with
companies, healthcare clinics,hospitals, et cetera and I'm
sure you've seen the headlineswith what it was the change
healthcare you see it in Franceand where you know healthcare
Wouldn't it be again pre-shoot achoir, probably something that

(21:37):
an organization of that size oreven any HIPAA compliant clinic,
isn't it something they shouldconsider?
Because if they don't, thenthey are exposed, I would think,
or have liability there.

Jeremy (21:50):
Yeah, look, yes, preach it to the choir.
But I will say, you know, we'renot the only company in the API
security space and I've talkedto a number of my peers and we
are all kind of like Blake said.
We're all looking at this likethe API really is that pot of
gold at the end of the rainbow,and, by the way, not only for
the reason that all the data isbehind it.
But I'll give you two otheraspects of it.

(22:11):
Number one is, when there areflaws in APIs, they tend to
expose the entire database right.
So the scale of API breachestends to be almost 10x non-API
breaches and we've been trackingthat for a couple of years and,
if anything, it has actuallygone up over the last couple of
years the kind of the differencein scale between them.

(22:33):
But the second thing that Iwould say about it is that we're
all of us who are sitting fromour perspective, looking at APIs
and looking at them every day,and looking at the huge volume
of internet traffic that is, apirequests and everything around
it.
We are still surprised thatmore people aren't paying
attention to this.
And you know, going back aboutfour or five years, gartner put

(22:55):
out a prediction, I think it wasin 2018, where they said it
might have been 2019, where theysaid, going forward, we expect
APIs to be the number one attacksurface and I want to say that
their time horizon was 2021 or2022.
And we've been tracking all theAPI breaches that we can find.
If you ever want to look at ourresearch around that, just go to

(23:17):
firetailio, go down to thefooter.
You'll find a link to the APIdata breach tracker.
We catalog them and wecategorize them to analyze what
went wrong in each of thosescenarios.
You can look at the spreadsheetdata there.
We make it all available foranybody to copy paste, play
around with the numbers, etcetera, et cetera.
We looked at that and we lookedat everything else going on

(23:37):
ransomware events and so on.
And I did a talk last year whereI said you know what?
I'm not sure I think Gartnermight have gotten this one wrong
.
And you know, not everybodyagrees with Gartner's research,
not everybody.
You can always look atstatistical analysis in
different ways.
What's the saying?
There are lies damn lies andstatistics or something right.
But you know there are waysthat you can kind of slice and

(23:57):
dice the data to get oneperspective or another.
But one of the most interestingthings about it was that I gave
a talk last year at Black Hataround the state of API security
and what we had been observingand seeing.
And there was a Gartner analystin the audience and I made the
statement that I didn't thinkthat APIs had actually become
the number one attack vector.
And the Gartner analyst emailedme afterwards and we went back

(24:24):
and forth in a little exchangeand they showed me some data and
they doubled down on theirposition and they said hey look,
this is what we think.
Here's why, here's the datasources for what we're thinking.
And very shortly thereafter westarted to see the largest
single event of last year, whichwas the Move it file transfer
software from Progress Software.

(24:45):
And it's really interestingbecause it's a piece of software
in use by thousands oforganizations around the world.
It got used to deliverransomware into these
organizations.
How did that ransomware getdelivered?
Over an API that the softwarewas exposing.
So all of these organizationsbought this third party piece of
software and didn't realizethat all of a sudden they were

(25:07):
now API providers, exposing APIsout to the internet by virtue
of using this software.
That API was abused to deliverthe malware package that kicked
off the ransomware chain ofevents to thousands of
organizations around the world.
So, after all of this exchange,I have to say Gartner was
probably right and, like I said,those of us who are looking at

(25:30):
the API security space, we'restill somewhat surprised that
there's not more focus andattention paid to APIs Because,
just like you know, you may haveheard the adage every company
is a software company now orbecoming a software company now.
Every software company isbecoming an API provider, and
that's where we think this isheading.

Craig (25:51):
Oh, go ahead.
I was just going to say do youthink that the problem is going
to get worse with the recentMicrosoft source code breach?

Jeremy (26:01):
I don't think that that on its own is going to
contribute significantly to it.
I think the problem is just onthe path towards getting worse
anyway.

Blake (26:10):
Right, what type of strategies does Firetail employ
to proactively block maliciousAPI calls?
I know that's a very simple andprobably a very complex
question in the same light, butyou know what type of strategies
are you going to point.

Jeremy (26:27):
It's pretty simple.
There's really two ways that welook at it.
So first way is the codelibraries that I mentioned
earlier, and what they do isthey look at what you have
defined as how your API shouldwork and anything that doesn't
match how your API should workcan be blocked right there, real
time in line.
Okay, that is a very simpleversion of it To run all of

(26:50):
those evaluations.
There's about eight to 10different things that we check
as the API call comes in.
Some of them are relativelystraightforward, like does the
API exist or is this just someprobing and enumeration to
discover what's running on thehost?
Right, that's a verystraightforward one.
If the API doesn't exist, or ifa specific aspect of the API

(27:11):
doesn't exist, obviously that'sa bad call.
Block that traffic.
Others are a little bit morelet's call them like medium
degree of difficulty, which islike my API says it expects
authentication of type JWT, javaWeb Token.
If I don't find a valid JWT inmy API request that's coming in,
then block that Still.

(27:32):
Others are much more complex.
That is like oh, we need tocheck the permission scheme, see
whether Jeremy is authorized toperform this action via API
call on this piece of data andthat's a three-part calculation
that we usually think of as userprinciple resource, and if
those three things don't map toyes, authorized, then block.

(27:57):
That's a little bit morecomplex of a calculation that
requires a little bit of datasharing and connections into a
permissions provider et cetera.
That's one aspect of it on thecode library side.
On the other side, what we do iswe have an agentless solution
which is a little bit out ofband, but what that does is it
observes all the traffic andthat can build up pictures of

(28:20):
specific types of maliciousbehavior happening against your
APIs.
You can actually use that toautomate firewall rules to block
certain actors, and you can dothat in an automated way.
You can do that for a period oftime or you can do that on a
permanent basis.
So that could be as simple.
As we're seeing a flood of bottraffic from this IP address,
let's put a rule in place for 24hours to block that IP address

(28:43):
to.
We are seeing a attemptedcredential stuffing attack from
combination of timestampgeolocation user agent.
We want to put a rule in placethat's very specific to that
entity and if we see that entitychange IP address but we see
the same type of behavior, thenwe can update the rule to the

(29:04):
new IP address.
So those are kind of twodifferent methods that we have,
one based off of the logs, onebased off of the API spec.

Craig (29:12):
So question going back to your move it example yeah, a
small business.
We're using a technology likemove it.
Could they use your technologyto like either opt out or
disable the API functionality?
You know like it's like allthese bells going off in my head
around small business owner.

(29:33):
A lot of companies we work withare defense industrial base.
They use Microsoft GCC high.
I'm assuming Microsoft GCC highhas some kind of API
connections by default and myquestion is can they use your
software to opt out, turn it off?
Granular security control youmentioned some good things about
firewall communications andmaybe geo charting and things

(29:55):
like that.
What are your thoughts there?

Jeremy (29:57):
no-transcript.
Well, like, the first thing thatthey would get from using our
software is the awareness thatthey're actually running an API,
and I would bet you that mostof them wouldn't even know that
they're running an API by virtueof using the software.
They would think we're using thesoftware.
It's a secure file exchange,probably an SFTP type of
connection.
There's no APIs associated withit.

(30:17):
So the first thing is you wouldgive them that awareness.
The second thing is you wouldthen give them awareness of
whether that API is actuallybeing actively used and for many
of them, I think that's themoment when the light bulb would
go off and they're like wait asecond, we don't have any known
partners that are using the APIaround this move it stuff.
We should just turn that off orput in place a firewall rule

(30:40):
that denies API traffic, whichwould be like port 443 onto that
specific endpoint, while stillenabling, like port 22, sftp.
So like just that overallvisibility and awareness of its
existence and its usage would bethe number one benefit that
they would get out of using oursoftware.
Actually, using the inlinecomponents would be more

(31:02):
challenging in that scenario,because the end customer
probably doesn't have access tothe source code to include the
inline components of a thirdparty piece of software.

Craig (31:11):
So what do they do there, if that's the case?

Jeremy (31:14):
Yeah, so what they do there is they do the log
analysis so they can ship logsfrom all the traffic to that API
to our back end and we cananalyze that, help them
understand that there ismalicious traffic happening
against that API.

Craig (31:27):
And then what are their options there?
Like, let's say, it's GCC high,there's an API they weren't
aware of and it's GCC action.

Jeremy (31:34):
So then it would be again like going back to what
Blake asked earlier.
It would be again likeimplement a rule, based on what
you're observing, that blocksthat traffic.

Craig (31:42):
Okay, so they can still have the option to implement a
rule, even though it's a thirdparty.

Jeremy (31:46):
Correct, correct.
And then at that point, be atthe network layer, not at the,
not specifically on the API, notin the code layer.
Yeah, correct, yeah.

Blake (31:57):
It seems like some of the solutions that I'm taking away
is to seize the communicationfrom a needed API data to
whatever software platformdevelopment is calling the API.
But what about the data that isbeing transmitted between those
two?
What type of security features?
And I mean description, I meanwhat?
Yeah, what happens with thatdata?

Jeremy (32:18):
So, first of all, we rely on you having encryption in
place that we kind of caneither piggyback on or sit
behind, because in order to dothe analysis around, let's say,
like the actual data that isbeing transmitted back and forth
, we need it to be in adecrypted form.
If it's all encrypted, all wecan tell you is, like traffic
patterns at a high level, you'regetting X volumes from these

(32:39):
sources, blah, blah, blah, right.
So on that line, though we dobreak down the every item in the
request payload that comesacross, there's a lot that gets
generated that I think a lot ofpeople don't realize in an API
request.
You might think that the APIrequest is just, let's say, like
your token and the parametersthat you've passed along, but

(33:04):
this whole header gets generated.
It'll probably get a couple ofcomponents like X forwarded for
from various different NATdevices as it transits networks
et cetera.
So we need that decryption sothat we can store all of that
and start to perform analysis onit.
We do IP address based lookupinformation around it.

(33:25):
We then have a what we call atagging system.
So every API call that weobserve, we have a set of
heuristics that we run to giveit to kind of grade that API
request based on a probabilisticscore of what is this?
Is this human or non-human, isthis bot or non-bot, is it

(33:46):
public or is it private?
Public private is actually morebased on the IP address.
But any of these types ofanalyses that we do, we also
look for signals, like a stringof API requests.
Basically, an API usage patternis like I connect to this API
the first time I connect, I justconnect to authenticate and

(34:07):
that's going to give me back mytoken.
After I authenticate, then Ican start requesting data and
performing actions.
Right, if we see somebodytrying to jump straight to an
action without going through theauthentication, that's another
pattern that we look at.
So we call that missing referbecause it's not being referred
from another part of theapplication.
So we look at a lot of thosetypes of things.

(34:28):
So all that tagging happens.
And then, last but not least,on the response that gets sent
back, we have a couple ofdifferent things that we look at
.
So there we look at theauthorization check, the
permissions graph that Imentioned earlier.
We also look at the dataelements that are composed in
the response.

(34:48):
We don't log PII.
We do have PII matchers thatwill analyze the response as
it's gone back out.
Just as an example, let's sayyou want to look for email
addresses as an easy example, wewill mask that and we'll put
email address in all caps in ourlogging.
But we will also note that PIIhas been shared, and we do that

(35:12):
across about 15 to 20 differentPII categories today.
That list is ever expanding aswe bring on customers from new
geographies.
Every government in the worldfeels like it's their duty to
come up with their own nationalID format, kind of the
equivalent of the socialsecurity number.
So that list is ever expanding.
Similarly, many countries yournational ID is not the same as

(35:36):
your passport ID, is not thesame as your social security
number, is not the same as yourretirement account, whatever.
So yeah, like that list of PII,checks can get really long,
really quick.
But we do kind of patternmatching on the data that is
being returned to help peopleget awareness over what they're
sending back out that they maynot be aware of.
So that's a pretty commonscenario, a pretty common use

(35:58):
case for customers that they'retrying to solve for.

Blake (36:01):
Also follow up and, from my understanding too, it sounds
like a lot of these people thatare doing these API calls app
developers, yada, yada don'tknow that they're happening,
which is scary, scary, scary,but it comes to mind, because if
they don't know that they'rehappening, then they're not
going to know to encrypt thoseAPI calls.

(36:24):
So it sounds like there's ahuge kind of gap in people that
aren't encrypting those APIcalls and I'm sure, as a large
percentage of the API calls thatyou're seeing, are probably
likely unencrypted.
Is that a fair statement orassessment?

Jeremy (36:39):
A percentage for sure.
This is getting better.
This is one of the few thingsthat I will say is getting
better.
The availability of zero costcertificates has been a real
boon for the internet.
Like let's encrypt and thecloud providers, issuing
certificates for free has becomea good thing.

(37:02):
Gone are the days when you hadto go through this crazy long
process with network solutionsor one of these legacy providers
to get SSL certificates.
So that's all getting better.
The ones where we see it isexactly to your point, blake.
It's the developer who's juststanding something up to get

(37:23):
something done quick and dirtyand doesn't want to go through
all of the hoops that they mighthave in their organization for
a proper release process orsomething like that.
But yeah, thankfully this one,we're getting a little bit
better as an industry yet.

Craig (37:42):
I think, to recap for our audience, the big takeaway is
making them aware of all theAPIs that they may have in their
organization.
That's number one.
Then, once they are aware ofwhat they have, then giving them
Intel into.
Here's what's happening, here'swhat's going on, and you should

(38:05):
, either if you're not usingthese functions, either at the
network layer, if they're thirdparty, block them to improve
your security and reduce yourrisk and liability.

Jeremy (38:15):
Yeah, look, I think that's really well said.
There's a bunch more that weget on onto it but at a high
level.
That is the core valueproposition.
I think anything withcybersecurity starts with
visibility and awareness.
If you don't know about it, youdon't know the risks that it
poses to your organization.
So, starting with thatvisibility and understanding of

(38:36):
whether it's good or one, thatit exists, whether it's good or
bad, how it's being used, that'sstep one in securing any
technology that you're using.

Craig (38:44):
Agreed.
So one last thing, and then weprobably should start wrapping
up.
But so do you find, jeremy,that, in educating people about
this, that it's a welcomedinformation, or is it like?

Blake (39:01):
this is too complicated.

Craig (39:03):
We're not using that.
That's kind of like.

Jeremy (39:07):
Yeah, look, I find that there's a lot of ignorance as
bliss.
If I'm perfectly honest aboutit, that saddens me a little bit
, because I think you are alwaysbest served by knowing.
Only by knowing can you make adecision about relative
prioritization.
I think what a lot of largerorganizations experience is some

(39:29):
combination of being overworkedand under-resourced, combined
with alert fatigue, combinedwith kind of an inherent stress
level.
That goes along withcybersecurity, because it is a
high risk, high stakes job andit is super, super important.
One of our lead investors theyhave the managing director there
, the president of the company.

(39:51):
He has this sayingcybersecurity is national
security, and that may not betrue for all organizations or
all customers, but the way Ithink about it is that
cybersecurity is organizationalsecurity.
Every company is becomingincreasingly digital and keeping
control over what you do, whatyou expose, what data you have,

(40:12):
how you're using it.
That is super critical foryourself and your organization
going forward.
Any security breach, you risklosing trust, reputational
damage as well as the directcost of paying for the breach
and recovering from it.
So I just think you should wantto be aware of all of the risks

(40:32):
that your organization has.
But what I see so often is again, like I said, overworked,
under-resourced, high stress,high alert, fatigue and usually
with a lot of really burningpriorities to address.
Whether that is training yourusers on not clicking those
phishing links, whether that islocking down basic email

(40:53):
security, whether that isgetting basic malware detection
and response on your endpoints.
People have tons and tons ofsecurity challenges that they
need to overcome.
Sadly, adding one more to thepile is often not as welcome as
I want it to be for us as acompany who is trying to help
people make their APIs strongerand more secure, but I do think

(41:17):
the growing shift to the cloudis bringing more awareness to
some of the new risks that arebeing posed to organizations,
apis being one of them.

Blake (41:28):
I think we're going to.
I got one more and I thinkwe've saved probably the most
challenging question for last.
Alright, let's go.
If the government were toapproach you to write some of
those compliance mandates thatyou said don't exist, what would
that look like?
What will we expect forcompliance mandates for API

(41:50):
calls?

Jeremy (41:50):
Yeah, so we may or may not actually be working on
something in this area.
It's not government related butwe are working on something to
just kind of put into the worldto help people know.
Here's a set of security bestpractices around APIs.
First would be gain awarenessof your inventory.

(42:11):
Have some mechanism and I willstress, it should be an
automated mechanism to build anawareness of the APIs that
you're using.
Apis are one of these thingsthat gets created and modified
so frequently by the developersthat you can't rely on a manual
Excel spreadsheet exercise tomaintain that inventory.

(42:32):
So that would be the number onething that I would say.
Number two is we've gonethrough multiple iterations of
APIs over the years.
I know, craig, you mentionedthat you work with a lot of
customers and who are heavy intothe Microsoft ecosystem.
Do you remember Microsoft inthe early 2000s talking about
web services and SOAP and XMLand WisDL?

(42:53):
Yeah, that was just V1 of APIs,right, like that really was the
beginning of two pieces ofsoftware talking to each other,
which is fundamentally what anAPI is Right.
So the evolution of the APIspace has gone through a number
of technology iterations, butsome of the core tenants from

(43:15):
that early phase are actuallyreally strong.
What was tough about SOAP, xml,wisdl, all that stuff was the
very strong document typedefinition stuff and the strong
contract stuff made it verycumbersome for developers to
build and launch new APIs.
So we've moved away from that.
But what we should be doingstill is good kind of

(43:38):
prescriptive documentation ofwhat our API should look like.
So that's those APIspecification files that we
talked about earlier.
They exist for all the modernlanguages where APIs are being
developed and various differentforms.
So the number two piece ofadvice is that all APIs should
be documented, and I don't mean,like the user facing,

(43:58):
documentation that explains whatit is.
I mean the technicaldocumentation that describes how
your API should work.
Beyond that, when we look at thebreach vectors and how APIs get
abused, the next set ofcontrols would really be very
strong around authenticationmethods, proper authorization

(44:20):
and avoidance of excessive datareturn.
Those would be like the nextset of controls and they
probably break down into aboutfour or five controls each.
So with all of that, you'reprobably looking at 15 to 20
controls to start off with, andthat's where I would say most
organizations start with those20.
And then you can get into thedeeper ones, where you uncover
something where you might wantto scratch beneath the surface,

(44:44):
but that's where my startingpoint on API compliance would be
Blake.

Blake (44:49):
And one more follow up is obviously creating awareness.
Here we are talking about thisand trying to spread awareness.
Even after this podcast isprobably going to be scary for
me to say it still may not beenough awareness out there for
businesses that are having andsharing information.
So how, in the future, could webring awareness to this?

(45:10):
What are you doing to bringawareness to this Beyond
podcasting, obviously, andcreating products around it?
But what has been successfulfor you guys to gain awareness?
What has been successful foryou guys to gain awareness
around this huge vulnerability?

Jeremy (45:30):
We share on our blog all the time, just firetailio.
I always stress firetailio.
We're constantly publishingthere, probably a few times a
week.
We do a twice a year APIsecurity report that where we
detail kind of new researchfindings like what's really new,

(45:51):
not just the change in thenumber of breaches and attacks,
but what are we learning?
How are attackers behaviorsevolving, what are some of the
new risks and breaches andthreats around API?
So we put that out twice a year, about every six months cycle.
We do a series of webinarsaround different aspects of APIs
, api risks in specificindustries as well.

(46:14):
We recently did one on thefinancial services industry.
We're doing one on the travelindustry the travel industry, by
the way, one of the heaviestusers of APIs as an industry and
when people say, oh, really,you say well, yeah, when's the
last time you flew on Expediaairline or you stayed at Expedia
hotel?
Like never, because thosethings don't exist, but I bet

(46:35):
you booked on Expedia before andhow do you think that booking
got transmitted Right?
So yeah, we're constantlypublishing what we're learning,
what we're finding new threats,new risks, et cetera.
We do share that on LinkedIn.
Pretty much everything that weput on our blog we share on
LinkedIn, so if you want tochoose one or the other to
follow, you'll get all of theinformation that we're putting

(46:56):
out there Awesome.

Blake (46:58):
Yeah, yeah, I'm thinking a lot about Plaid too, because I
know that's one that a lot ofpeople use like essentially
connecting financial data frompoint to point.
And yeah for sure.
Now I'm nervous.

Craig (47:10):
Well, I think, at least from our perspective for pen
testing, security assessments,things like that we can bring
awareness, you know, around APIsecurity and the need to be
aware of what APIs you have inyour organization, make you
aware of the risks of those APIs, give you advice on, hey, you
know, here's how we can block orstop, or whatever on the

(47:32):
network level, you know, giveyou options.
So I think that could be how wecould build.
I think the knee-jerk reaction,though, sadly, is that I would
bet most medical practice owners, or most business owners that
are smaller, are probablythinking oh, this is probably
above my head, this isn't myproblem yeah.
This is probably Microsoft'sproblem or probably XYZEMR

(47:55):
providers, this is probablyMicrosoft's problem, yeah, yeah,
I think that when you broughtthe example, jeremy, about the
move it and the basically thedoorway into dropping ransomware
, I think that should be thelight bulb that goes off for a
lot of those folks that you'reprobably using one or more
services at a third-party levelthat you're probably not aware

(48:16):
of.
So, again, bringing awarenessto you and to your organization
and then, you know, giving youthe visibility and then the
ability to have options to takeaction.
And one thing that also comesto mind and I'll kind of close
with this is I was reading theother week about how the CIO
title is really dropping to moreof the CISO title and also the

(48:42):
CISO is now more skin in thegame.
Yeah, you know, if they dosomething wrong or they get
hacked, it's their neck on theline, that they have liability
and sometimes even criminalliability beyond, you know, just
termination of employment.
So I'm seeing a shift there andI'm also seeing a shift that I
was doing some research aroundhow companies that have that are

(49:06):
a bit larger, or maybe anonprofit or more organized
company that has a board ofdirectors, how the board of
directors now is starting to getcybersecurity awareness
training and they can't just belike, oh, I don't know about
that.
You know they're actuallyhaving input now and
requirements aroundcybersecurity awareness and

(49:26):
training.
So I think that you know, Ithink we're, I think that, like
you said before, jeremy,regulation, and while they might
not be perfect, at least theybring awareness and light to
this problem and I think thateverybody should certainly, you
know, assess their situation,especially at the API side of

(49:47):
things now, because I'mcertainly, you know, a bit
scared now based on, you know,our discussion today.

Blake (49:54):
There's a simple solution Just shut down the internet.

Jeremy (49:57):
Yeah right.

Craig (49:57):
Just turn it off.
I'm just going to go back topen and paper.

Blake (50:00):
Yeah, there you go Absolutely.
Sorry, Jeremy.
What were you going to say?
I didn't mean to jump in on you.

Jeremy (50:05):
No, no, not at all, and I was just going to say like,
look, awareness of anything isalways the first step.
What you mentioned around theevolution of the CIO and the
CISO titles kind of converging.
I'm seeing that we've got twopeople on our advisory board who
are former CISOs at largerorganizations.
They're seeing that as well,especially with the shift to the

(50:26):
cloud.
When you think about the CIOtitle and what that CIO was
typically responsible forprimarily the technical
infrastructure of anorganization that is much, much
easier than back in my days inthe late 90s, early 2000s, when
that was part of my mandatebuilding and maintaining
infrastructure as well assecuring it.

(50:46):
It's all a lot easier If I canjust flip the switches on 20 EC2
instances on AWS to provide theserver infrastructure that I
need.
That's a heck of a lot easierthan Rackin and Stackin servers
right and changing swapping outhard drives.
So really, the focus of whatenables the organization, in the
same way that infrastructuredid in the past, is keeping the

(51:08):
organization secure.
As long as the organization issecure, everybody else can go do
their job day to day and keepthings moving forward.
When you have a breach or youhave an incident, it tends to
bring down the wholeorganization and shut things
down, and so this concept ofsecurity being an enabling
function very much the way thatIT was an enabling function in

(51:30):
the past is how I see thatevolution playing out.

Craig (51:34):
I think that's well said and I also think, in closing,
that going back and drillinghome to most people that are
listening or watching you haveto invest in the technologies
and the knowledge and thetraining around awareness.
If you don't have the awarenesseven at your home like using
the analogy of home security ifyou don't have cameras and all

(51:55):
these different layers andyou're not aware of issues, then
you don't know how to react tothem.
So you could be doing a greatjob with your cybersecurity and
your policies and yourprocedures, but if you've
completely overlooked vendorrisk and API security, then
you've got two open doors thatare in the back of your house
that cyber criminals can justwalk right in and cause an awful

(52:17):
breach in situation for yourreputation, absolutely.

Blake (52:23):
All right, guys, let's go ahead and wrap this up.
Thank you so much to our guests.
Mr Jeremy Snyder, the founderand CEO at Fyretailio, we will
make sure to link him in thedescription so you guys can
check out what he's doing overthere, and I'm sure we will talk
to you very soon, jeremy.

Jeremy (52:42):
Thanks, jeremy, that's great.
Thanks so much for having me.
Guys Appreciate it.
Bye-bye, bye-bye.

All Episodes

Episode Transcript

Popular Podcasts

Are You A Charlotte?

Dateline NBC

Stuff You Should Know

.css-15opob5{left:0;position:absolute;top:0.8rem;} All Episodes

.css-14f5ked{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:2;overflow:hidden;}Navigating the Complexities of API Protection and Compliance

Episode Transcript

Popular Podcasts

.css-r6mb8g{margin:0;word-break:break-word;display:-webkit-box;-webkit-box-orient:vertical;box-orient:vertical;-webkit-line-clamp:1;overflow:hidden;}Are You A Charlotte?

Dateline NBC

Stuff You Should Know

All Episodes

Navigating the Complexities of API Protection and Compliance

Are You A Charlotte?