Informal security chat with Beyond Identity's Founding Engineering Nelson, our host Reece Guida, and founder and CEO of FireTail Jeremy Snyder on why the market needs an easy way for people to block API attacks or attempted API attacks.

Transcription

Reece

Hello, and welcome to another episode of "Cybersecurity Hot Takes." It's me, your host, Reece Guida. I'm here with Nelson, like always, our founding engineer, but today we have a special guest, Jeremy. Jeremy, why don't you introduce yourself to everybody?

Jeremy

Yeah. Happy to, and thanks for having me on, Reece and Nelson. Yeah. My name's Jeremy Snyder. I'm the founder and CEO of a company called FireTail. You can find us at firetail.io. We're focusing on API security, especially as applied to modern architectures.

Reece

Nice. And Jeremy, what the heck are you doing here? You have a hot take, right?

Jeremy

Yeah. You know, and really my hot take around API security is that there's been a lot of talk about API security, especially with the wave of recent large-scale incidents around it. And most of the talk that you see out in the marketplace is around detection and response and kind of focusing on gathering logs and making decisions around that. And I feel like that's actually giving up on trying to bring preventative approaches to API security, and that's not what the market needs. What the market needs is easy way for people to block API attacks or attempted API attacks. And that's what I'm here to talk about today.

Reece

Nice. Nelson and I feel very strongly about prevention because that is fundamentally what we do at Beyond Identity, as well as work with some detection and response players on the authentication side of things. But, you know, we talked a little before the podcast hit record and we discovered that Nelson and I, you know, are kind of newbies when it comes to this. So, I think it might be interesting for the viewers to kind of hear about some common ground and learn along with us here when it comes to API security. So, you were telling us about something that happened in the land down under recently that might bring more attention to this problem.

Jeremy

Yeah. So, there was the...I guess the second-largest telecom provider in Australia was breached, thanks to an unauthenticated API that became public. And, you know, just as kind of a best practice, any unauthenticated API is really only designed either as an authentication endpoint itself, or it's designed for internal purposes. If you've got anything else sitting out on the internet, even if it's serving up public data, you wanna do some kind of authentication checks against it.

And in this case of what happened to this telco provider, this API, exposed to the public internet, allowed for pure, unfettered, unauthenticated access to the API, which then enabled some little bit of kind of, let's call it, on endpoint lateral movement that enabled data trove discovery and exfiltration to the tune of 11.2 million people.

Reece

Wow.

Jeremy

And that's the important thing to remember here. It's not just 11.2 data records. That's 11.2 people's, you know, private information that was exfiltrated there.

Reece

Wow. And, you know, when API security breaches happen, what does the detection process look like? You know, sometimes when there's a credential compromise, it takes a while for people to even notice that there's been a breach. Is it kind of similar in the land of API security?

Jeremy

It kind of depends on what kind of breach happens. There are kind of four primary attack vectors around API today. Two of them are related to credentials and, you know, things like authentication and authorization. Those two, the most kind of, let's say, common detection and response capabilities are really trying to gather the logs from the APIs from the activity in terms of, you know, what was queried, what records were returned back, in terms of kind of, you can think of like the request and the response payloads. Really bringing that into one central location is the way to kind of start that detection and response process.

The challenge around detection and response for APIs is that patterns can be very inconsistent. So, unlike things like network traffic where you have, let's say, common baseline that's relatively easy to detect and then do anomaly detection around, API traffic patterns really depend on what's actually happening, what the user is doing. And I don't know about you, but, you know, the way that I use an app may be very different from the way that you use an app, and so it's hard to kind of trigger off of detection and response pattern or traffic monitoring. And so that's where kind of the detection and response problem starts with API security.

Reece

Yeah. You can't really get a baseline, from what it sounds like, or at least it would be really hard to do that. So, why is prevention so important then, given that, and how does that really work with APIs?

Jeremy

So, prevention is really important because APIs are kind of for the large part today being deployed on cloud platforms. And what we know about cloud platforms is that things move really, really quickly. And so if you think, "Hey, I'm just gonna, like, put this API out there and then we'll focus on kind of monitoring and detection response," you've got a number of challenges there. One is, again, on those fast-moving cloud platforms, you don't know for sure that the logs are actually flowing to the right location.

You can't really guarantee that the right level of instrumentation or observability is put in place because I might build an API on a serverless function, Nelson might build one on an EC2 instance, and Reece, you might build one on, you know a container on Kubernetes or one of the cloud-native Kubernetes services, all of which log to different locations. And so, again, you've got problems on detection and response. And so what kind of needs to happen is that preventative controls need to be put in the hands of the developer who's launching the API because otherwise, you've really got kind of no guarantee of a level of security monitoring or security preventative control measures in place.

Nelson

Sounds like cataloging and kind of discovering these endpoints has a huge role in there. What are some of the tools that you would use for something like that?

Jeremy

So, actually, that is where some detection and response can actually serve a good purpose. So, building an inventory off of traffic patterns, that's interesting. But then, you know, the behavior detection and the behavior monitoring becomes really challenging. So, if you look at, let's say, a platform like AWS, you can look at cataloging calls from API gateways, from WAFs, from network or application load balancers, bringing that stuff together in one location and kind of parsing throughs URIs in the logs, and building an inventory off of that. But you're absolutely right, Nelson. Last year, there was a survey of CISOs, and the number one challenge around APIs was just API visibility and inventory.

Reece

Wow. You know, you said something that stood out to me, Jeremy. You talked about empowering developers when it comes to API security. And at Beyond Identity, we help secure code by making sure that developer impersonation can't happen when code is checked in. So, we also believe that security starts with the developer, albeit in a different realm. So, Nelson, I'm wondering what you think about, you know, APIs from your experience. Like, you use them all the time. Is security really at the forefront of an average developer's mind?

Nelson

It's hard.

Reece

Nelson's got an adorable baby who's just living her life.

Jeremy

I'm sure she's concerned about API security as well.

Reece

She's very concerned.

Nelson

She's learning as we speak. That's an interesting question as a developer that doesn't necessarily work in the security space very much. Before kind of working at Beyond Identity, my exposure to securing APIs was very low. I kind of understood that if you have something that's public, you should make sure that if it has some level of exposure to critical data, then you should take precautions there. But authentication for APIs has always been kind of a fussy idea. How do you find folks securing APIs in a way that's effective?

Jeremy

Yeah. There's not a lot of effective API security out there today, to be honest. I do find people kind of relying on, let's say, old school or legacy patterns for trying to secure their APIs today, put it behind a WAF, put it behind an API gateway, maybe lean into some of the kind of basic functionality there. That could be things like preventing access to certain routes or methods based on WAF rules, or that could be things like checking for an authentication token or for rate limiting on an API gateway. But typically, you find that you don't have coverage for all of the major attack vectors.

There's been about 30-ish large-scale public API breaches over the last couple of years. We've been kind of cataloging them and doing root cause analysis, and I don't think I've seen a single customer who had an effective approach today to address all of the major attack vectors. And that is something that we're trying to make easier for developers over time.

Reece

Yeah. So, you know, most big problems have solutions that start with small steps, right?

Jeremy

That's right.

Reece

So, from what you're saying, it sounds like the trend of attacks in your space is accelerating.

Jeremy

Yep.

Reece

What advice would you give to developers to help kind of mitigate this problem other than, hey, check out firetail.io?

Jeremy

Yes. Yeah. Well, that's obviously the first step, but in all seriousness, I would say, look, talk to your security team and hope that they've been, you know, out there doing research around what the attack vectors are, and then try to understand what your organization's approach to security is. That might be a perimeter-oriented approach where you do have, you know, a WAF and an API gateway. But then actually, next step, the two largest attack vectors are really authentication and authorization.

Find out what the kind of standard approach that your organization has for its applications with regards to those two things, and make sure that you align to that, and don't try to reinvent it. The more you can reduce the number of, let's say, authentication and authorization mechanisms that your application or development team is supporting, the less risk you have. Or when you do have a problem, you've got a larger brain trust to go to, to go figure out, you know, where the problem lies and make kind of architectural changes to stamp it out in the future.

Reece

You know, you're talking our language when it comes to authentication and authorization.

Jeremy

Yeah.

Reece

I think we can end by saying that we have that in common, and it's a good place to make sure that you are having everything locked down. Hey, Jeremy, thank you so much for coming on the podcast today. We really appreciate you enlightening us on all things API security, and we wish you the best of luck. Until then, everybody, stay tuned for yet another episode of Hot Takes coming at you soon. Have a good one.

​