Navigating the Complexities of API Protection and Compliance

Unlock the secrets to ironclad API security with Jeremy Snyder of Firetail as we navigate the often treacherous terrain of digital safety. Peering into the murky depths of API exploitation, Jeremy brings clarity to how Firetail's cutting-edge tools not only bolster developers' efforts in constructing impenetrable APIs but also stand guard, thwarting real-time threats. Our digital lives, intertwined with these invisible gateways—be it a simple food order or an endless scroll on social media—demand such vigilance. Alongside relatable anecdotes, we examine the insidious nature of API breaches, from impersonation to lax authorization, and how Firetail's innovations are reshaping the landscape of cybersecurity.

As digital fortresses become more complex, we probe the battlefield of API security threats and compliance, where Firetail emerges as an ally. Attuned to the silent war against automated attacks that exploit API vulnerabilities, we reveal how disabling network telemetry in the name of cost-saving can be a false economy, leaving businesses exposed. The conversation branches out to encompass the intricate dance of compliance, with a spotlight on the necessity for airline industry-like regulations in tech. This nuanced discussion lays bare the urgency of a comprehensive security posture management system, capable of unmasking covert APIs before they fall prey to cyber predators.

Concluding our expedition through the digital thicket, we shine a beacon on the opaque world of API visibility and the pivotal role of security awareness within organizations. Jeremy illustrates how Firetail's sophisticated software unveils hidden APIs, transforming the nebulous into the known. The dialogue turns to the art of log analysis and pattern recognition as we dissect the intricacies of keeping personal data under lock and key. Penetration testing and proactive security assessments rise as the clarion call for CIOs and CISOs, now standing at the vanguard of accountability for breaches. All paths lead to one destination: the imperative need for investment in technology, shar

Support the show - Call 877-468-2721 or visit https://petronellatech.com

Please visit YouTube and LinkedIn and be sure to like and subscribe!

Chapters

• 0:00 API Security Company Firetail Overview
• 7:40 API Security Threats and Compliance
• 17:23 API Security and Compliance Trends
• 30:36 API Visibility and Security Awareness
• 46:20 API Security and Awareness Discussion

Transcript

Craig: 0:39

Cool, all right, welcome to another podcast. We've got Blake Gray Lou and a special guest, Jeremy Snyder. Please introduce yourself.

Jeremy: 0:51

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

Blake: 1:10

Tell us about Firetail for those who may not be familiar.

Jeremy: 1:14

Yeah, we are about a two year old company working in the API security space.

Jeremy: 1:18

As I mentioned, we're a software company.

Jeremy: 1:20

We make about three or four different software components that are really designed to help people who are making APIs either make them more secure by design or secure them at runtime, and we can get into some of the details around that.

Jeremy: 1:35

But the kind of the short version of it is that we've got like some inline components that developers can embed in their APIs that do security checking inline real time. So that's what I mean when I say like help people ship secure APIs. And then on the other side, we've got a set of components that will do things like discover APIs running on cloud platform. So if your company is running on AWS, azure, gcp, we can help bring continuous visibility into APIs new APIs that might get launched, existing APIs that might get updates to them, new functionality on them, etc. As well as kind of monitoring all the usage and traffic around those APIs, looking for malicious patterns, looking for things like data leakages and so on. And yeah, in a nutshell, that's what we do and you know happy to go into any more detail on any of that that might be of interest.

Craig: 2:24

So quick question that comes to mind Is it just for really simple terms? Is it fair to say that your software is kind of like a security water filter for existing APIs out there to make you? Know, clean it up and make it better.

Jeremy: 2:40

Look, it can be, but only that one component that I mentioned, that's the embedded component. That is sort of like a security water filter and to kind of continue on that analogy, let's say that, like your municipal water system has rules around what acceptable water is right. That might be the pH level, that might be the purity level, etc. Most of the time when developers build APIs, if they're following kind of modern let's call them development best practices, they should be writing something called an API specification. You'll often hear this referred to as a swagger file or an open API spec OAS, and what that does is it describes how the API should function.

Jeremy: 3:21

One of the gaps that we identified is that you have this description that says what the API should do, but usually there's nothing that checks whether that is what the API actually does. So our little inline component takes that specification and turns it into an inline filter. So as API traffic comes in, our component we call them the firetail code libraries will check the API call that's coming in. Does it match what the specification expects an API call to look like? If yes, proceed. If no, block it and throw the appropriate error message that corresponds to which part of it wasn't right and log that somewhere.

Craig: 4:00

So it's almost like extended detection and response for eight APIs.

Jeremy: 4:05

In a way and although I, like I, don't want to sound more grandiose than we really are we're not yet at a point where we're taking that data and correlating it with a bunch of signals from, let's say, the operating system layer or from network or whatever. So I would call it more detection and response oriented specifically to APIs right now. Sure.

Blake: 4:26

Sure, tell us what an API, tell us about API vulnerability and what that would look like for people that aren't familiar with those types of activities and threats.

Jeremy: 4:38

Yeah, and let me start by just kind of describing at a high level how APIs usually kind of function, right. So most people use APIs every day. In fact, I would wager if you're using the internet, you are using APIs every day and you just don't really realize it. Every time you pick up your phone and you do something like a mobile food order or you order ride share or really social networking, any social media any of that, very little is actually happening on the phone. What really happens is that on the phone, the app that you're using packages up the thing that you're looking to do. That might be Jeremy looking to look at Blake's profile on LinkedIn, right? So there's a request where I say I am Jeremy and I have some piece of information that identifies me as Jeremy. That could be a user ID, that might be a security token that LinkedIn has provided to me after I logged in. And then I have the aspect that says like I want to look at Blake's profile and maybe Blake's profile ID is one, two, three, four, five, just to put it simply. So what's really happening at that point in time? When I am, my LinkedIn app say show me, blake's profile is my. The app on my phone says use this token, send it to LinkedIn over an API and request the user profile one, two, three, four, five to display right. So that's how an API works.

Jeremy: 5:57

Now what happens from a security perspective is there's a couple of things in there. One is that some APIs can be tricked into giving my token to other people so that they can impersonate me. But more often than not, one of the big problems is that when I request to look at this user profile one, two, three, four, five there's an authorization check that happens, which is should Jeremy be allowed to look at 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 and I say I'm Jeremy, with this token, I want to view Blake's ride history and Blake is the user one, two, three, four, five. Should I be allowed to do that? No, there's a permissions check that clearly says like, no, you're not allowed to look at another user's ride history.

Jeremy: 6:48

But this abuse of flaws and authorization categorically that's the number one category of flaws that we see on APIs. It doesn't tend to be a problem in people using mobile apps themselves. There might be some controls inside the app. There might be some interchange of data between the app and the back end. That makes it all kind of clear and checks the permissions and everything. But when hackers abuse those APIs, they don't abuse them through the mobile apps. They're going to go straight to the API and they're going to programmatically try to circumvent controls on the back end to extract data. Does that kind of answer your question and give something of a scenario?

Blake: 7:28

Yeah, absolutely.

Craig: 7:30

So quick question comes to mind Do cybersecurity experts, researchers, pen testers use your product and suite to kind of as a tool set?

Jeremy: 7:41

So mostly our product is used directly by people who are building their own APIs.

Jeremy: 7:45

So it's mostly software companies, mobile app companies, iot companies, really any kind of technology firms right, they're the ones that use our product to test the security of their own APIs, and what we give them is we give them a view of all the APIs they're running, including the ones that their developers have created that the security team didn't know about.

Jeremy: 8:07

We give them a picture of what those APIs look like to the outside world, so like what the APIs are exposing, let's say, the functionality that's being exposed, the variables that might be passed in, etc. And we do an analysis of that picture to tell them where the security risks are around the API, so almost like a stoplight report, something like that. We tend to call it security posture management, because it's kind of this like discovery, inventory, assessment. And, by the way, the last step of that is that we give recommended remediations. We're like, hey, your API looks like this. You shouldn't really be using integer IDs, because that makes your API very prone to data scraping, as an example. That's the type of visibility and the type of recommendations that we give them.

Blake: 8:54

Cool. What type of like vulnerabilities have you guys found in your research? I mean it sounds like there's some scary stuff. I mean I'm assuming in some software I know, and I mean even like Intuit, for example you know, I don't want to call anybody out specifically and that is not who we're referencing, but they have my social security number or business ID and they're using a call to API for whatever you know paste banking and I mean what type of scary and sensitive things have you seen being passed through APIs? And I'm sure you've probably seen some intense vulnerabilities that maybe these software developers don't even consider.

Jeremy: 9:35

Well, let me give you a few different things. One is something that we see on our own APIs that we stand up every day. We're constantly launching APIs to test them for various purposes test our software with it, test vulnerabilities, etc. First of all, one of the scariest things that I think we see, just from a kind of big picture perspective, is the amount of automated traffic hitting anything on the internet nowadays is insane. So we're a small company, right? We're a two year old company headquartered in Northern Virginia. We've got, you know, 12 people spread across the US, ireland, finland, etc. We're a very small company, but even us, with our you know small company, small brand name, etc. Our APIs that we put online tend to see traffic within about three minutes, and I've talked to other cybersecurity researchers and experts and this is pretty consistent Anything you put online will get probed within a very, very short period of time.

Jeremy: 10:38

On the back of that, the probing is not one time drive by probing. It's not. Oh, let me just see what's running here. It's oh, let me see what's running here. I got a response from a particular IP address or particular DNS name. Let me issue some follow up requests. Is it running WordPress? Is it running Drupal? Is it running some common software that I might know about? Is it running Microsoft Exchange? On and on to try to iterate over and discover what the tech stack is behind it, and then typically launching exploits against a particular tech stack once it's been determined. So this is like I said, it's not one time drive by like, oh, just did I get a response? Is there an active target there? What is the target? What is it running? Is it vulnerable to these exploits that I'm seeing and again, you're seeing that within minutes.

Jeremy: 11:28

We also, along with that, we also see probing For tokens and secrets and passwords and so on. So very often when you're launching an app, you'll have some you know, service account passwords or things like that that are associated with it. Those are sometimes stored in like config files, environment variable files, etc. We all we see requests looking for those files. So there's that. That's one thing that I think is just everybody should be aware of, and the way I usually tell people to think about this is just remember, hackers have cloud and hackers have automation too. It costs pennies per hour to run these continuous probes of what's out there on the internet. Right, it's not expensive and it is a high value, low cost activity for them, because when they do discover that one system that is running the unpatched version of JetBrains or whatever it is, boom, there's a target that they can actively exploit.

Craig: 12:22

So one thing that comes to mind for me is like port scanning right.

Jeremy: 12:26

Yeah, yeah. So what this is?

Craig: 12:29

Yeah, so it's like port scanning for the or at the API layer. But I guess my question is I'm assuming with your platform you can program in the API so the customer wants to kind of monitor and be notified when those actions happen. Yeah, but if you don't have something like your technology, how what they get, how would they know?

Jeremy: 12:49

The best would be if they have general network telemetry that's running across their entire IP range so they do know if some new service goes online. But that is often not the case and especially on cloud platforms. A lot of organizations will kind of by default turn off that monitoring because there's a cost associated with it. So they only turn it on once they know that there's an approved new production service running at IP address 1.2.3.4. Yeah, let's turn on logging for that platform once we know about it. So you know it can be a big blind spot to your question, craig.

Blake: 13:24

We play a lot in the compliant space and our last guest we talked a lot about aerospace and something that we never really considered. I mean, obviously, because we're not in aerospace, but there's no physical security mandates around aircrafts and there's so much technology in these aircrafts. So the unsexy question, but also the question that I find myself asking, is is there any compliance mandates that are grounding, api security?

Jeremy: 13:56

Yeah, I wish there were, and are we moving?

Blake: 14:00

towards. That Is that we're moving.

Jeremy: 14:03

Look? I hope so, as of yet we have seen nothing at a national level or at what you would think of as an industry level, right? So if you think of some of the top compliance standards that are out there, you have NIST standards, you have things like PCI or HIPAA that are more industry specific. Currently, none of them have specific car valves for APIs. 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 ones where there's a lot left to the auditor's interpretation of a particular rule set. There's not a ton of super prescriptive controls, but I'm glad that it got mentioned there for the first time. Otherwise, we do work with customers in other parts of the world, so some, for instance, in Southeast Asia, and we have seen things like the monetary authority of Singapore start to call them into question for things around local banking regulations. But let's say at a global level, something like ISO standards no, at a US national level, nist no. Industry level, pci very first introduction of it.

Jeremy: 15:16

I like compliance standards coming in, whether you always agree with the rule sets or not, whether you always agree with the controls, and this is something that I spent five years working on cloud security, day to day. Many of our customers were always concerned with am I hitting this benchmark or this compliance standard or this regulatory compliance requirement, et cetera, and they would argue about particular things. I don't care if you argue or disagree with the control. The point to me is that it actually makes you think of that check Right and you actually go look at this thing and what is my configuration over here or what is my control over here, even if at the end I'm going to tell 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 of that component. So I really hope that we're on the path towards more API compliance standards, but it's been slow coming and, from my perspective as somebody working in the space, we're behind where we need to be.

Craig: 16:12

So one of the things that comes to mind for me is quite a concern is, like you mentioned before, I think that most people are using APIs and not realizing it. So a really long time ago, I used to use an app called Mint and it would aggregate all your bank accounts and all your stuff. So you're trusting these companies. I'm assuming, through API, that they're going to log in and request and fetch the data that you want. But if there's no standard, then if I get breached I'm really the one holding the bag.

Jeremy: 16:47

Yeah, absolutely. And I mean Mint is a perfect example, because you're spot on Craig the way Mint aggregated your bank account, credit card, mortgage payment, all the things that go into this financial picture of Craig is APIs and the new version of a credit karma. They've been bugging me to migrate as well, but the new version of it is just going to be the new implementation of the same set of APIs, et cetera. And you're right, and if you think 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 bad actor to have.

Craig: 17:23

Exactly. So I'm almost sorry, Blake, I just want to finish this one thing. So I'm almost envisioning that this would even be more powerful in the UK with GDPR, because we don't have in North America yet an equivalent GDPR. So I'm just wondering how that affects your business model there.

Jeremy: 17:43

Yeah, so funny enough. I mean we have a lot of our R&D in Europe, in fact, pretty much all of it. We operate the company on GDPR standards because when we looked at it like hey, we're spread between North America and Europe we just found that GDPR brings a lot of scrutiny to our own data handling practices, even for us, again, as a small young company, and we figured let's just do that globally and let's just operate on that standard. We're going to be better stewards of our customer data. As a result of following all that guidance To your point, there have been a lot of organizations that have reached out to us around just general customer privacy of the data.

Jeremy: 18:22

One of the things that we've seen, in kind of going back to the question about what do we see, that's kind of scary.

Jeremy: 18:28

One of the scary things we've seen is companies having APIs that process PII that nobody knew about and we see instances where an API request might look fine but the API response is inadvertently sending back PII and that could be as much as like a very common scenario that we see is APIs that return too much data. So I'll go back to that example of requesting Blake's profile. It's very easy for a developer to write a query in the application that says select star from user database, where user equals Blake or 12345. And instead of actually looking at what data specifically needs to be displayed let's say, in the case of LinkedIn, it should be just first name, last name, job title, employer they would just give back everything First name, last name, job title, employer, home address, email address, phone number, et cetera. All this information why? Because it's easier for the developer to write a select star query, and so identifying these APIs that are returning PII beyond what is expected is definitely a very common use case and scenario that we've seen customers looking to solve.

Craig: 19:45

And one thing that comes to mind there. Sorry, I don't mean to dominate this, blake, I know you've got another question, but one thing so, like with medical, with HIPAA compliance, I'm sure there's APIs with EMR and EHR systems.

Blake: 19:57

Yeah, for sure.

Craig: 19:58

At the consumer level. All these doctors' offices want you to sign up for their MyChart app or whatever.

Blake: 20:03

Yeah.

Craig: 20:04

My point is most people, I would assume, are not reading all the fine prints, so they're like yeah, yeah, yeah, I just want my medical record. My point is that wouldn't it be considered a breach, a data breach, if there was some kind of API flaw or issue with the giving exposure without the consumer knowing?

Jeremy: 20:22

Yes, yes, it absolutely would be.

Craig: 20:24

So I think that our country needs an overhaul of HIPAA compliance because it was enacted in 1996 by Bill Clinton quite old now in 2024. But my point is I would advocate for API security standards to kind of get elevated and in cap salated into that model.

Jeremy: 20:42

Yeah, I mean, look, you're preaching to the choir here.

Blake: 20:45

I have this thing that's been spitting through my head ever since you mentioned it, but everybody knows the myth that if you find the bottom of a rainbow, 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 golden egg of security, because normally, for example, if you wanted to gain access to somebody's bank account or credit card information or social security number or whatever right, you'd have to respectively access different, like you may have to get into their Equifax account, or maybe their bank account or what, but then in this case, you just find an API that they're using and it's all there.

Blake: 21:27

So there you are and they're inspired tail with essentially like a SEAL Team 6, right.

Jeremy: 21:35

Look, I never want to promise more than we can deliver, but certainly we're there to help in any way that we can, whether it is our software, whether it is our team coming in to help you recover from an incident that you might have or to run an assessment of your own APIs. Yeah, absolutely, it would help.

Craig: 21:53

So, going back to the HIPAA thing that we talked about a minute ago, with the API security there, so with companies, healthcare clinics, hospitals, et cetera and I'm sure you've seen the headlines with what it was the change healthcare you see it in France and where you know healthcare Wouldn't it be again pre-shoot a choir, probably something that an organization of that size or even any HIPAA compliant clinic, isn't it something they should consider? Because if they don't, then they are exposed, I would think, or have liability there.

Jeremy: 22:29

Yeah, look, yes, preach it to the choir. But I will say, you know, we're not the only company in the API security space and I've talked to a number of my peers and we are all kind of like Blake said. We're all looking at this like the 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 is behind it. But I'll give you two other aspects of it. Number one is, when there are flaws in APIs, they tend to expose the entire database right. So the scale of API breaches tends to be almost 10x non-API breaches and we've been tracking that for a couple of years and, if anything, it has actually gone up over the last couple of years the kind of the difference in scale between them. But the second thing that I would say about it is that we're all of us who are sitting from our perspective, looking at APIs and looking at them every day, and looking at the huge volume of internet traffic that is, api requests and everything around it. We are still surprised that more people aren't paying attention to this. And you know, going back about four or five years, gartner put out a prediction, I think it was in 2018, where they said it might have been 2019, where they said, going forward, we expect APIs to be the number one attack surface and I want to say that their time horizon was 2021 or 2022. And we've been tracking all the API breaches that we can find.

Jeremy: 23:52

If you ever want to look at our research around that, just go to firetailio, go down to the footer. You'll find a link to the API data breach tracker. We catalog them and we categorize them to analyze what went wrong in each of those scenarios. You can look at the spreadsheet data there. We make it all available for anybody to copy paste, play around with the numbers, et cetera, et cetera. We looked at that and we looked at everything else going on ransomware events and so on.

Jeremy: 24:18

And I did a talk last year where I said you know what? I'm not sure I think Gartner might have gotten this one wrong. And you know, not everybody agrees with Gartner's research, not everybody. You can always look at statistical analysis in different ways. What's the saying? There are lies damn lies and statistics or something right. But you know there are ways that you can kind of slice and dice the data to get one perspective or another. But one of the most interesting things about it was that I gave a talk last year at Black Hat around the state of API security and what we had been observing and seeing. And there was a Gartner analyst in the audience and I made the statement that I didn't think that APIs had actually become the number one attack vector. And the Gartner analyst emailed me afterwards and we went back and forth in a little exchange and they showed me some data and they doubled down on their position and they said hey look, this is what we think. Here's why, here's the data sources for what we're thinking.

Jeremy: 25:15

And very shortly thereafter we started to see the largest single event of last year, which was the Move it file transfer software from Progress Software.

Jeremy: 25:24

And it's really interesting because it's a piece of software in use by thousands of organizations around the world. It got used to deliver ransomware into these organizations. How did that ransomware get delivered? Over an API that the software was exposing. So all of these organizations bought this third party piece of software and didn't realize that all of a sudden they were now API providers, exposing APIs out to the internet by virtue of using this software. That API was abused to deliver the malware package that kicked off the ransomware chain of events 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 the API security space, we're still somewhat surprised that there's not more focus and attention paid to APIs Because, just like you know, you may have heard the adage every company is a software company now or becoming a software company now. Every software company is becoming an API provider, and that's where we think this is heading.

Craig: 26:30

Oh, go ahead. I was just going to say do you think that the problem is going to get worse with the recent Microsoft source code breach?

Jeremy: 26:39

I don't think that that on its own is going to contribute significantly to it. I think the problem is just on the path towards getting worse anyway.

Blake: 26:49

Right, what type of strategies does Firetail employ to proactively block malicious API calls? I know that's a very simple and probably a very complex question in the same light, but you know what type of strategies are you going to point.

Jeremy: 27:06

It's pretty simple. There's really two ways that we look at it. So first way is the code libraries that I mentioned earlier, and what they do is they look at what you have defined as how your API should work and anything that doesn't match how your API should work can be blocked right there, real time in line. Okay, that is a very simple version of it To run all of those evaluations. There's about eight to 10 different things that we check as the API call comes in. Some of them are relatively straightforward, like does the API exist or is this just some probing and enumeration to discover what's running on the host? Right, that's a very straightforward one. If the API doesn't exist, or if a specific aspect of the API doesn't exist, obviously that's a bad call. Block that traffic. Others are a little bit more let's call them like medium degree of difficulty, which is like my API says it expects authentication of type JWT, java Web Token. If I don't find a valid JWT in my API request that's coming in, then block that Still. Others are much more complex. That is like oh, we need to check the permission scheme, see whether Jeremy is authorized to perform this action via API call on this piece of data and that's a three-part calculation that we usually think of as user principle resource, and if those three things don't map to yes, authorized, then block. That's a little bit more complex of a calculation that requires a little bit of data sharing and connections into a permissions provider et cetera. That's one aspect of it on the code library side.

Jeremy: 28:48

On the other side, what we do is we have an agentless solution which is a little bit out of band, but what that does is it observes all the traffic and that can build up pictures of specific types of malicious behavior happening against your APIs.

Jeremy: 29:03

You can actually use that to automate firewall rules to block certain actors, and you can do that in an automated way. You can do that for a period of time or you can do that on a permanent basis. So that could be as simple. As we're seeing a flood of bot traffic from this IP address, let's put a rule in place for 24 hours to block that IP address to. We are seeing a attempted credential stuffing attack from combination of timestamp geolocation user agent. We want to put a rule in place that's very specific to that entity and if we see that entity change IP address but we see the same type of behavior, then we can update the rule to the new IP address. So those are kind of two different methods that we have, one based off of the logs, one based off of the API spec.

Craig: 29:51

So question going back to your move it example yeah, a small business. We're using a technology like move it. Could they use your technology to like either opt out or disable the API functionality? You know like it's like all these bells going off in my head around small business owner. A lot of companies we work with are defense industrial base. They use Microsoft GCC high. I'm assuming Microsoft GCC high has some kind of API connections by default and my question is can they use your software to opt out, turn it off? Granular security control you mentioned some good things about firewall communications and maybe geo charting and things like that. What are your thoughts there?

Jeremy: 30:36

no-transcript.

Jeremy: 30:36

Well, like, the first thing that they would get from using our software is the awareness that they're actually running an API, and I would bet you that most of them wouldn't even know that they're running an API by virtue of using the software.

Jeremy: 30:48

They would think we're using the software. It's a secure file exchange, probably an SFTP type of connection. There's no APIs associated with it. So the first thing is you would give them that awareness. The second thing is you would then give them awareness of whether that API is actually being actively used and for many of them, I think that's the moment when the light bulb would go off and they're like wait a second, we don't have any known partners that are using the API around this move it stuff. We should just turn that off or put in place a firewall rule that denies API traffic, which would be like port 443 onto that specific endpoint, while still enabling, like port 22, sftp. So like just that overall visibility and awareness of its existence and its usage would be the number one benefit that they would get out of using our software. Actually, using the inline components would be more challenging in that scenario, because the end customer probably doesn't have access to the source code to include the inline components of a third party piece of software.

Craig: 31:49

So what do they do there, if that's the case?

Jeremy: 31:52

Yeah, so what they do there is they do the log analysis so they can ship logs from all the traffic to that API to our back end and we can analyze that, help them understand that there is malicious traffic happening against that API.

Craig: 32:05

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: 32:13

So then it would be again like going back to what Blake asked earlier. It would be again like implement a rule, based on what you're observing, that blocks that traffic.

Craig: 32:21

Okay, so they can still have the option to implement a rule, even though it's a third party.

Jeremy: 32:25

Correct, correct. And then at that point, be at the network layer, not at the, not specifically on the API, not in the code layer. Yeah, correct, yeah.

Blake: 32:36

It seems like some of the solutions that I'm taking away is to seize the communication from a needed API data to whatever software platform development is calling the API. But what about the data that is being transmitted between those two? What type of security features? And I mean description, I mean what? Yeah, what happens with that data?

Jeremy: 32:57

So, first of all, we rely on you having encryption in place that we kind of can either piggyback on or sit behind, because in order to do the analysis around, let's say, like the actual data that is being transmitted back and forth, we need it to be in a decrypted form. If it's all encrypted, all we can tell you is, like traffic patterns at a high level, you're getting X volumes from these sources, blah, blah, blah, right. So on that line, though we do break down the every item in the request payload that comes across, there's a lot that gets generated that I think a lot of people don't realize in an API request. You might think that the API request is just, let's say, like your token and the parameters that you've passed along, but this whole header gets generated. It'll probably get a couple of components like X forwarded for from various different NAT devices as it transits networks et cetera. So we need that decryption so that we can store all of that and start to perform analysis on it.

Jeremy: 33:59

We do IP address based lookup information around it. We then have a what we call a tagging system. So every API call that we observe, we have a set of heuristics that we run to give it to kind of grade that API request based on a probabilistic score of what is this? Is this human or non-human, is this bot or non-bot, is it public or is it private? Public private is actually more based on the IP address. But any of these types of analyses that we do, we also look for signals, like a string of API requests. Basically, an API usage pattern is like I connect to this API the first time I connect, I just connect to authenticate and that's going to give me back my token. After I authenticate, then I can start requesting data and performing actions. Right, if we see somebody trying to jump straight to an action without going through the authentication, that's another pattern that we look at. So we call that missing refer because it's not being referred from another part of the application. So we look at a lot of those types of things. So all that tagging happens. And then, last but not least, on the response that gets sent back, we have a couple of different things that we look at. So there we look at the authorization check, the permissions graph that I mentioned earlier. We also look at the data elements that are composed in the response.

Jeremy: 35:27

We don't log PII. We do have PII matchers that will analyze the response as it's gone back out. Just as an example, let's say you want to look for email addresses as an easy example, we will mask that and we'll put email address in all caps in our logging. But we will also note that PII has been shared, and we do that across about 15 to 20 different PII categories today.

Jeremy: 35:55

That list is ever expanding as we bring on customers from new geographies. Every government in the world feels like it's their duty to come up with their own national ID format, kind of the equivalent of the social security number. So that list is ever expanding. Similarly, many countries your national ID is not the same as your passport ID, is not the same as your social security number, is not the same as your retirement account, whatever. So yeah, like that list of PII, checks can get really long, really quick. But we do kind of pattern matching on the data that is being returned to help people get awareness over what they're sending back out that they may not be aware of. So that's a pretty common scenario, a pretty common use case for customers that they're trying to solve for.

Blake: 36:39

Also follow up and, from my understanding too, it sounds like a lot of these people that are doing these API calls app developers, yada, yada don't know that they're happening, which is scary, scary, scary, but it comes to mind, because if they don't know that they're happening, then they're not going to know to encrypt those API calls. So it sounds like there's a huge kind of gap in people that aren't encrypting those API calls and I'm sure, as a large percentage of the API calls that you're seeing, are probably likely unencrypted. Is that a fair statement or assessment?

Jeremy: 37:18

A percentage for sure. This is getting better. This is one of the few things that I will say is getting better. The availability of zero cost certificates has been a real boon for the internet. Like let's encrypt and the cloud providers, issuing certificates for free has become a good thing. Gone are the days when you had to go through this crazy long process with network solutions or one of these legacy providers to get SSL certificates. So that's all getting better. The ones where we see it is exactly to your point, blake. It's the developer who's just standing something up to get something done quick and dirty and doesn't want to go through all of the hoops that they might have in their organization for a proper release process or something like that. But yeah, thankfully this one, we're getting a little bit better as an industry yet.

Craig: 38:21

I think, to recap for our audience, the big takeaway is making them aware of all the APIs that they may have in their organization. That's number one. Then, once they are aware of what they have, then giving them Intel into. Here's what's happening, here's what's going on, and you should, either if you're not using these functions, either at the network layer, if they're third party, block them to improve your security and reduce your risk and liability.

Jeremy: 38:54

Yeah, look, I think that's really well said. There's a bunch more that we get on onto it but at a high level. That is the core value proposition. I think anything with cybersecurity starts with visibility and awareness. If you don't know about it, you don't know the risks that it poses to your organization. So, starting with that visibility and understanding of whether it's good or one, that it exists, whether it's good or bad, how it's being used, that's step one in securing any technology that you're using.

Craig: 39:23

Agreed. So one last thing, and then we probably should start wrapping up. But so do you find, jeremy, that, in educating people about this, that it's a welcomed information, or is it like?

Blake: 39:40

this is too complicated.

Craig: 39:42

We're not using that. That's kind of like.

Jeremy: 39:46

Yeah, look, I find that there's a lot of ignorance as bliss. If I'm perfectly honest about it, that saddens me a little bit, because I think you are always best served by knowing. Only by knowing can you make a decision about relative prioritization. I think what a lot of larger organizations experience is some combination of being overworked and under-resourced, combined with alert fatigue, combined with kind of an inherent stress level. That goes along with cybersecurity, because it is a high risk, high stakes job and it is super, super important.

Jeremy: 40:23

One of our lead investors they have the managing director there, the president of the company. He has this saying cybersecurity is national security, and that may not be true for all organizations or all customers, but the way I think about it is that cybersecurity is organizational security. Every company is becoming increasingly digital and keeping control over what you do, what you expose, what data you have, how you're using it. That is super critical for yourself and your organization going forward. Any security breach, you risk losing trust, reputational damage as well as the direct cost of paying for the breach and recovering from it. So I just think you should want to be aware of all of the risks that your organization has.

Jeremy: 41:13

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 burning priorities to address. Whether that is training your users on not clicking those phishing links, whether that is locking down basic email security, whether that is getting basic malware detection and response on your endpoints. People have tons and tons of security challenges that they need to overcome. Sadly, adding one more to the pile is often not as welcome as I want it to be for us as a company who is trying to help people make their APIs stronger and more secure, but I do think the growing shift to the cloud is bringing more awareness to some of the new risks that are being posed to organizations, apis being one of them.

Blake: 42:07

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

Jeremy: 42:29

Yeah, so we may or may not actually be working on something in this area. It's not government related but we are working on something to just kind of put into the world to help people know. Here's a set of security best practices around APIs. First would be gain awareness of your inventory. Have some mechanism and I will stress, it should be an automated mechanism to build an awareness of the APIs that you're using. Apis are one of these things that gets created and modified so frequently by the developers that you can't rely on a manual Excel spreadsheet exercise to maintain that inventory. So that would be the number one thing that I would say. Number two is we've gone through multiple iterations of APIs over the years.

Jeremy: 43:19

I know, craig, you mentioned that you work with a lot of customers and who are heavy into the Microsoft ecosystem. Do you remember Microsoft in the early 2000s talking about web services and SOAP and XML and WisDL? Yeah, that was just V1 of APIs, right, like that really was the beginning of two pieces of software talking to each other, which is fundamentally what an API is Right. So the evolution of the API space has gone through a number of technology iterations, but some of the core tenants from that early phase are actually really strong. What was tough about SOAP, xml, wisdl, all that stuff was the very strong document type definition stuff and the strong contract stuff made it very cumbersome for developers to build and launch new APIs. So we've moved away from that.

Jeremy: 44:12

But what we should be doing still is good kind of prescriptive documentation of what our API should look like. So that's those API specification files that we talked about earlier. They exist for all the modern languages where APIs are being developed and various different forms. So the number two piece of advice is that all APIs should be documented, and I don't mean, like the user facing, documentation that explains what it is. I mean the technical documentation that describes how your API should work.

Jeremy: 44:45

Beyond that, when we look at the breach vectors and how APIs get abused, the next set of controls would really be very strong around authentication methods, proper authorization and avoidance of excessive data return. Those would be like the next set of controls and they probably break down into about four or five controls each. So with all of that, you're probably looking at 15 to 20 controls to start off with, and that's where I would say most organizations start with those 20. And then you can get into the deeper ones, where you uncover something where you might want to scratch beneath the surface, but that's where my starting point on API compliance would be Blake.

Blake: 45:28

And one more follow up is obviously creating awareness. Here we are talking about this and trying to spread awareness. Even after this podcast is probably going to be scary for me to say it still may not be enough awareness out there for businesses that are having and sharing information. So how, in the future, could we bring awareness to this? What are you doing to bring awareness to this Beyond podcasting, obviously, and creating products around it? But what has been successful for you guys to gain awareness? What has been successful for you guys to gain awareness around this huge vulnerability?

Jeremy: 46:09

We share on our blog all the time, just firetailio. I always stress firetailio. We're constantly publishing there, probably a few times a week. We do a twice a year API security report that where we detail kind of new research findings like what's really new, not just the change in the number of breaches and attacks, but what are we learning? How are attackers behaviors evolving, what are some of the new risks and breaches and threats around API? So we put that out twice a year, about every six months cycle.

Jeremy: 46:45

We do a series of webinars around different aspects of APIs, api risks in specific industries as well. We recently did one on the financial services industry. We're doing one on the travel industry the travel industry, by the way, one of the heaviest users of APIs as an industry and when people say, oh, really, you say well, yeah, when's the last time you flew on Expedia airline or you stayed at Expedia hotel? Like never, because those things don't exist, but I bet you booked on Expedia before and how do you think that booking got transmitted Right? So yeah, we're constantly publishing what we're learning, what we're finding new threats, new risks, et cetera. We do share that on LinkedIn. Pretty much everything that we put on our blog we share on LinkedIn, so if you want to choose one or the other to follow, you'll get all of the information that we're putting out there Awesome.

Blake: 47:37

Yeah, yeah, I'm thinking a lot about Plaid too, because I know that's one that a lot of people use like essentially connecting financial data from point to point. And yeah for sure. Now I'm nervous.

Craig: 47:49

Well, I think, at least from our perspective for pen testing, security assessments, things like that we can bring awareness, you know, around API security and the need to be aware of what APIs you have in your organization, make you aware of the risks of those APIs, give you advice on, hey, you know, here's how we can block or stop, or whatever on the network level, you know, give you options. So I think that could be how we could 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 probably thinking oh, this is probably above my head, this isn't my problem yeah.

Craig: 48:31

This is probably Microsoft's problem or probably XYZEMR providers, this is probably Microsoft's problem, yeah, yeah, I think that when you brought the example, jeremy, about the move it and the basically the doorway into dropping ransomware, I think that should be the light bulb that goes off for a lot of those folks that you're probably using one or more services at a third-party level that you're probably not aware of. So, again, bringing awareness to you and to your organization and then, you know, giving you the visibility and then the ability to have options to take action. And one thing that also comes to mind and I'll kind of close with this is I was reading the other week about how the CIO title is really dropping to more of the CISO title and also the CISO is now more skin in the game. Yeah, you know, if they do something wrong or they get hacked, it's their neck on the line, that they have liability and sometimes even criminal liability beyond, you know, just termination of employment.

Craig: 49:37

So I'm seeing a shift there and I'm also seeing a shift that I was doing some research around how companies that have that are a bit larger, or maybe a nonprofit or more organized company that has a board of directors, how the board of directors now is starting to get cybersecurity awareness training and they can't just be like, oh, I don't know about that. You know they're actually having input now and requirements around cybersecurity awareness and training. So I think that you know, I think we're, I think that, like you said before, jeremy, regulation, and while they might not be perfect, at least they bring awareness and light to this problem and I think that everybody should certainly, you know, assess their situation, especially at the API side of things now, because I'm certainly, you know, a bit scared now based on, you know, our discussion today.

Blake: 50:33

There's a simple solution Just shut down the internet.

Jeremy: 50:35

Yeah right.

Craig: 50:36

Just turn it off. I'm just going to go back to pen and paper.

Blake: 50:39

Yeah, there you go Absolutely. Sorry, Jeremy. What were you going to say? I didn't mean to jump in on you.

Jeremy: 50:44

No, no, not at all, and I was just going to say like, look, awareness of anything is always the first step. What you mentioned around the evolution of the CIO and the CISO titles kind of converging. I'm seeing that we've got two people on our advisory board who are former CISOs at larger organizations. They're seeing that as well, especially with the shift to the cloud.

Jeremy: 51:06

When you think about the CIO title and what that CIO was typically responsible for primarily the technical infrastructure of an organization that is much, much easier than back in my days in the late 90s, early 2000s, when that was part of my mandate building and maintaining infrastructure as well as securing it. It's all a lot easier If I can just flip the switches on 20 EC2 instances on AWS to provide the server infrastructure that I need. That's a heck of a lot easier than Rackin and Stackin servers right and changing swapping out hard drives. So really, the focus of what enables the organization, in the same way that infrastructure did in the past, is keeping the organization secure. As long as the organization is secure, everybody else can go do their job day to day and keep things moving forward. When you have a breach or you have an incident, it tends to bring down the whole organization and shut things down, and so this concept of security being an enabling function very much the way that IT was an enabling function in the past is how I see that evolution playing out.

Craig: 52:13

I think that's well said and I also think, in closing, that going back and drilling home to most people that are listening or watching you have to invest in the technologies and the knowledge and the training around awareness. If you don't have the awareness even at your home like using the analogy of home security if you don't have cameras and all these different layers and you're not aware of issues, then you don't know how to react to them. So you could be doing a great job with your cybersecurity and your policies and your procedures, but if you've completely overlooked vendor risk and API security, then you've got two open doors that are in the back of your house that cyber criminals can just walk right in and cause an awful breach in situation for your reputation, absolutely.

Blake: 53:02

All right, guys, let's go ahead and wrap this up. Thank you so much to our guests. Mr Jeremy Snyder, the founder and CEO at Fyretailio, we will make sure to link him in the description so you guys can check out what he's doing over there, and I'm sure we will talk to you very soon, jeremy.

Jeremy: 53:21

Thanks, jeremy, that's great. Thanks so much for having me. Guys Appreciate it. Bye-bye, bye-bye.