API Security: Where Cloud Security Meets Application Security with Jeremy Snyder | SecOps Vision 2024

Hello, welcome to SecOps Vision for 2024. My name's Jeremy Snyder, I'm the founder and CEO of a company called Fire Tail. We work in the API security space.

I'm really excited to be here today. I've got a lot that I want to get through in about 25 minutes, so I will apologize in advance that I might go a little bit quickly through some things. But the good news is everything's recorded.

Both the video and the slides will be available after. So if you miss anything, don't worry. You'll always have the chance to go back and check it.

So the topic of my talk today is API security and why API security is where cloud security meets application security. And before we dive in, I just wanna say a few words about myself to give some context to how I kind of arrived at some of these ideas. And what my work has in the last 25 years in technology has led me to understand about the convergence of these two worlds of cloud and application security.

I spent the first half of my career as a hands-on keyboard practitioner in IT and cybersecurity before transitioning into more product and customer facing roles in a number of cloud companies, including AWS Raincloud and then in cloud security with Divvycloud and later rapid seven. And then spent some time doing m and a in the cybersecurity space, specifically looking at topics like cloud security, like application security, and like the evolution of this space. So the first thing I want to talk about is just kind of the context for where we are today in 2023, going up to 2024, where this vision is intended for in moving forward in looking at kind of the state of the modern web.

And one of the things that is really important and fundamental to understand is that APIs actually connect us all. You'll hear a lot of analogies of how they're the plumbing of the modern internet, the duct tape of the modern internet. I like to think of them as the connective tissue of the modern internet.

And I'm gonna share some stats in just a moment right now about that. And what I really mean, and I think one of the first things to understand is that actually 83% of all internet calls today, not bandwidth, but the number of requests sent on the internet are actually API calls. So it's not your Google search or mine, it's actually two applications talking to each other.

And that's really what APIs are. They're the way that applications talk to each other. We are at a pace right now where we're adding 2000 or more APIs per year.

And when I say adding 2000 APIs, I mean public API services. And more than 62% of developers are actually using third party APIs in the modern applications that they're building. And I just think to put the context around all of this, you know the number, you'll hear a number of 1 trillion APIs coming in the next couple of years.

But I think a more instructive way to think about it is that for every single human on earth, we're getting close to there being 125 APIs out on the modern internet. And I know those numbers seem overwhelming, but I think one way to kind of contextualize it on a regular day-to-day basis is that when you do a simple everyday transaction like order mobile food delivery, your one order generates more than 25 API requests. And you, you kind of look at this diagram here.

You'll see I send my order from my mobile device to a backend cloud service that's a set of API calls that cloud service, then sends it on to a restaurant to a delivery driver, sends my payment details to a payment processing service. All of those are API calls and multiple API calls. I validated with somebody who works in this space and we got to 25 API calls counting in just a couple of minutes.

And then my friend said, listen, there's a lot more. But you get the point. There are literally dozens of API calls in a single transaction.

And also in those transactions you'll see sensitive information like my name, my phone number, my email address, my home address, my delivery location. And you'll also see my payment details in there. So we have sensitive PII plus mission critical data crossing the wires between multiple third parties in API calls every day on the modern web.

So how does this all connect to cloud security? And I wanna kind of rewind for a second and take a few steps back to talk about the evolution of cloud security over the last several years. You know, if we think back to kind of the 20 15 16 17 timeframe, what we saw time and again was we would see these data leak errors and you would see them typically, you know, the classic is the open S three buckets for those of you who are familiar with AWS, but it's not a problem specific to AWS and it's not a problem specific to, uh, file storage services.

It happens across database instances, it happens across virtual machines, compute services, et cetera. But it's the classic configuration error of leaving something open to the public. And so if you think about that from an attack perspective, it's not actually an attack.

It's literally a misconfiguration done by most likely a human who created the cloud environment and exposed the data and to try to understand where this falls in a cybersecurity strategy, which is, you know, really the point of today's talk is to kind of inform cybersecurity strategies going forward. I think it's helpful to think about the way you build and design cloud environments in four quadrants. And you'll see the X axis here represents time.

And the dotted line here in the middle represents kind of the transition from pre-production environments into production environments. And the way I like to think of that is that you've got kind of a, uh, an application layer above that arrow and you've got an infrastructure layer below the arrow, and then you've got pre-production to the left and production to the right. And don't worry if you can't read the kind of details there.

That's just mapping out kind of the seven layer OSI tech stack onto that environment to understand how this all pay plays out. So let's think about those leaks or those breaches for a second. So where did they all fall onto the spectrum of breaches?

They're all in kind of this lower right hand quadrant and that really maps to production infrastructure environments. And over time what's happened is those production infrastructure environments have become well addressed by a set of tools that Gartner classifies as CSPM, cloud Security Posture Management. And what that really does is it kind of collects information about your infrastructure, all of the configurations of your infrastructure and all of the resources that you're consuming in those cloud environments and lets you know if you've got exposures in any of those places.

Now, over time what's happened is that we've now entered a second wave of kind of data breaches on cloud environments, and now we really are getting into attacks because attackers realize that going after the low hanging fruit of the exposed data is becoming a harder and harder problem. As defenders get better at having real time ongoing visibility of those cloud, uh, infrastructure environments and locking down those configurations. And also the cloud providers, you have to give them credit, they've made it a lot harder for you as a user to make that mistake and accidentally expose your data.

So in the second wave, what we've got is we've now got examples where attackers understand that they can breach a cloud environment through one exposed to attack surface and then utilize TTPs for lateral movement to exfiltrate data. Now, I won't go too much into the details of, uh, the Capital One hack from 2019, but suffice it to say that it, you know, started at the application layer pivoted from the application onto a virtual machine from a virtual machine out to an identity and access management layer, and then from that identity and access management layer into a storage environment where the actual, uh, let's say the juicy data was to be found. And so we've got now a situation where the CSPM view of kind of addressing the configuration of the infrastructure resources would not be sufficient to protect the cloud environment.

So great, that was about four years ago now. So what have the tools developers done in response to that? They've actually expanded the coverage for, uh, what they are providing.

And we've seen a shift from, you know, what Gartner would call wave one cloud security, CSPM to kind of the current wave of cloud security, C-N-A-P-P, cloud native application protection platforms. And if you look here, I've kind of drawn a little, uh, shaded rectangle there to try to help explain what's increased in the coverage of these tools platforms as we've moved forward into 2023. And you'll notice that we now go above that line, you know, going above the infrastructure layer into the basic operating system container and into the application and the application package layer, primarily through vulnerability management and eliminating vulnerabilities and third party vulnerabilities.

And if you think about a shift left aspect on this, there's a little bit of static code analysis that can also happen to kind of eliminate, um, let's say bad security practices in your coding environments and, and kind of bake out some of those common flaws that you might have seen. But what you'll notice at the top of that was that APIs were left exposed. And so as we get into the current state, I think the most important thing that you could take away from this slide that I have up, up on the screen is that APIs now represent 90% of the attack surface of web apps.

And so that's where you start to see this new, you know, this modern convergence of API centric application development happening on cloud platforms and the coverage real of CNAP platforms really extending up but falling just below the API security layer. And that's why I say API security is the meeting point for where cloud security and application security converge because APIs represent the attack surface of web apps and they are actually becoming the most frequent attack vector. Um, I'll just take a quick second for a sidebar here.

You know, earlier this year I did a talk where I said I don't know if that that Gartner prediction came true. And someone from Gartner actually saw my talk, reached out and provided some real compelling backup data, uh, to kind of confirm that in fact, you know, they've looked at their own analysis, they've looked at the IBM data breach, uh, the DBIR, the data breach incident report, and they do confirm that APIs are implicated in more than 70% of all modern breaches. And if you look at the single largest incident this year, that being the move it, uh, file transfer ransomware wave of attacks on against the progress software platform, um, the, then you see that actually in that attack, if you look at the technical analysis, the most likely introduction method, uh, or attack surface for how the ransomware, uh, payload was delivered was through a file upload resume, API.

And so APIs really are involved in the vast majority of modern breaches. Alright, so let's move forward. So we've spent at Fire Tail, we've spent some time analyzing about 10 years of API breach data to try to understand, okay, if APIs are this really relevant attack surface, what do we need to do about it?

What are the threats? What are the attack vectors that we need to think about and how do we look at it? And I think the most interesting conclusion, and there's a, a link at the bottom of the screen, I'll share a link and a QR code later on to get the data behind all of this.

Um, we've been analyzing all these breaches and what we see very, very consistently is that the number one and number two risk factors are authentication and authorization. And if you wanna scratch the surface below that, you start to get into things like governance and configuration. So some of the same threads around governance and configuration, but a set of new attack factors around authentication and authorization.

So from our perspective, if you try to take a step back and you say, well, what's really going wrong there? Is this a traditional kind of network security view? No, it's actually a new set of threats around attacking the business logic of the API is the API authenticating people properly or callers properly, and I shouldn't say people because it's really kind of system to system communication, but are the APIs authenticating the callers properly?

Are they checking authorization? Are they checking authorization on each follow up post authentication request? And that's a common problem that we've seen in a number of cases.

Now, I won't spend too much time to go through all of these examples today, but I've just shown a couple here on the screen. I'll just pick one of them as an example and I'll pick the one on the right here. Optus.

So this was a breach in September of 2022 that exposed 11 million records. And what you saw was an API that was designed for internal consumption, but through one network configuration change all of a sudden became a public API. And what ends up happening, you have a challenge where no authentication or improper authentication was put in place.

So we see a couple things around our analysis of this. One is that if you want to understand the breaches or the risk of breaches, you actually need to be looking at a different layer of data visibility than what you might look at from a traditional network attacker perspective. If you're trying to defend a network, you typically focus on something like a firewall or perimeter layer defense.

But when you look at the data and the telemetry that you can get off of that type of, uh, network, uh, packet analysis, you're lacking all of the arguments and the visibility around authentication and authorization. So that's one thing that we've noticed and that's a a real common thing. The other thing is that in almost every API security incident that we've looked at, we see more than one thing go wrong.

So if you take that Optus example, yes, we had authentication problems, but we also had that network configuration change and it's the convergence of those things. So that again, kind of talks to the fact that APIs are very often placed on a cloud network, cloud network where you need to understand the context of the network around it in addition to the business logic risks of the API. So, uh, this is not specific to any one industry, but of course industries that are very heavily API reliant are overrepresented.

Um, so technology of course, who builds API software companies, um, but interestingly enough, kind of what I think of as modern digital supply chains have also been heavily linked to a number of breaches and disclosures. The automotive industry in particular, uh, connected cars, there's been some great research earlier this year around that and the risks of the APIs on connected cars, uh, you could literally walk up to a vehicle, get the vehicle ID number, which you can usually get by looking through the, the, uh, windshield and use that to unlock and start the engine on a number of modern connected cars. Uh, the hospitality industry, if you think about kind of online, uh, booking sites and how they connect to, uh, airline and hotels and rental car companies, all of that is API connectivity as well.

So those are kind of overrepresented in the sample size, but um, but it is a pretty broad range of companies that have had API breaches. So how have we seen companies try to address these emerging technology problems as they, you know, as their developers move forward on, let's say building a lot of APIs, how do the security teams tend to respond? The number one challenge that we hear from a lot of organizations is they, developers tend to get ahead of security and security is left running behind.

And what do they need to do? They need to catch up. How do they do that?

Typically by establishing visibility first, and that's usually by a discovery and inventory process. And then secondarily, by analyzing all of the discovered assets against a policy framework that can help them prioritize and understand what's good or what's bad about the APIs that they might have running in the world. So that's a pretty common approach and what you'll usually hear this referred to as is kind of security posture management, uh, security posture management is a general kind of cybersecurity strategy for, uh, going through that process of establishing visibility, getting an inventory, then assessing that inventory, understanding what's good or bad, and then getting some tips around remediation and how to, uh, defend going forward.

Uh, great. Um, and I do see some questions trickling into the chat. I'm gonna try to get to those towards the end here, so I do thank you.

Please keep them calming. Um, the other thing that we've seen pretty consistently is there's a, you know, a common perception that innovation is always ahead of security and that developers don't care about security. And in fact, you know, I've taken this little screenshot here just just to have a little bit of fun.

If you do type into Google, at least here in the states, developers don't press the letter C the number one thing suggested is care about security. And we've realized that fire tail, that this is actually a real challenge because developers build the APIs in most organizations. Developers are responsible for the designs of the APIs and developers are responsible for the business logic of the APIs.

And if the risk is really at that business logic layer, uh, then what can we do to make developers aware of what, what needs to be done or what mistakes they might be making as they build their APIs. Um, so that's something that we've very heavily focused on here. I won't spend too much time going through fire tail, um, but for anybody who is interested, we do help with that kind of security posture management approach towards, uh, discovering your APIs, observing them, assessing them against a framework of common security, uh, best practices around API design and development, as well as centralizing an audit trail to log and monitor API traffic for risks.

And, uh, just a couple of screenshots I'm gonna kind of go through quickly. Uh, so yeah, you've got the discovery visibility, observability aspects, and then you've got an enforcement framework that is an a set of open source code libraries. I do encourage anybody who's interested to go check out our GitHub repos for our open source code libraries.

Um, you can actually ship a secure API with inline defense and protection, uh, completely open source, and then the ability to assess APIs against, again, those common security best practices, uh, get a centralized audit trail, examine how your traffic is going, and I'm gonna pause here and leave it on the screen. So, uh, there's the QR code for our research analysis around API security for anybody who's interested. And also, of course, feel free to reach out to me anytime with any, uh, with any questions or follow up comments you might have more than happy to engage.

And I'm going to turn my attention towards a couple of the questions that have popped in on the chat. Uh, gimme just one second here. Uh, yeah, the bucket issue is indeed an ongoing trend and I know it's not solved.

Um, I know there are still plenty of customers who do, uh, leave their buckets open to the world or whatever the equivalent. Um, I'm not as familiar with AWS and, and Google terminology, so I can't remember what the equivalent services are called. I think blob storage might be on Azure.

Um, but yeah, that can, that is still an ongoing issue. So I'm not, I I didn't mean to suggest that CSPM has completely solved the open, uh, bucket or the open database issue. I know it is still happening, but I think it has gone down quite a lot.

If you look at kind of data breach trackers or cloud breach trackers, you will see fewer of those types of issues than you might've seen, like let's call it five, six years ago. Uh, uh, next question. APIs need secrets.

I secrets while in use are one of the most, uh, insufficiently protected, um, aspects of an APII would actually a hundred percent agree with that. Uh, secrets protection and secrets management is a real challenge in general and around APIs as well. Um, and it's really interesting because in some of the breach instances that we have seen, um, we do see the leakage of API secrets leading to a number of attacks.

Those tend to be in some of the more involved API breaches that we've seen. Um, most of the breaches were kind of at a similar or, or a parallel point to where we were with cloud security in the sense that attackers are mostly going after the low hanging fruit. Most of the time the low hanging fruit is just trying to, um, is just trying unauthorized access to data.

Um, a very simple example is that you'll often see in API calls, you'll see something like a user ID equals one and a, um, let's say a profile ID equals one. And so the most common attacks are just changing profile ID equals 2, 3, 4, et cetera, to kind of access and scrape data. Now to the question that came in secret to management around APIs, um, some of the challenges that we've seen are, for instance, um, uh, API tokens being set in cookies, uh, and maybe even in persistent cookies.

And the attackers having the ability to kind of go into those cookies, extract the secret and then use them elsewhere outside of that session. Uh, that is something that we've seen in a couple of attacks, but again, those are some of the more involved, let's call them more advanced attacks around APIs. And, uh, great.

Another question that came in. Yeah. Can API ops help improve the security aspects?

Great question. The answer is yes. So let's talk about this for a second.

So API ops for, you know, I, I think it's still a term that is, some people might have different opinions about what it means means, but when I think about something like API ops, just like I think about something like, um, ML ops or, or data ops or what have you, what it usually means is, you know, you kind of monitor the structure of in, in the design of the thing that you're building and then you monitor it in production as to how it's used. And so from the standpoint of APIs, one of the most interesting things is actually collecting the telemetry data from the APIs. And that telemetry data can be, uh, any number of things that can be, you know, where your call's coming from, your caller patterns.

Um, that can be a specific pattern of API access, uh, that you expect. So for instance, it must go through the authentication endpoint first and then from authentication it should go to search to users, whatever it is for your specific application. But then understanding differences in behavior patterns as to when you have violations of those processes or when you have unexpected behaviors can be very beneficial.

Um, the second thing that I think is actually often overlooked in this is actually checking whether the the request and the response match. And what I mean by that is, you know, when you design an API, you'll very often specify what can be requested and then what should go back out to the caller. Um, but what we have seen in a number of cases is that APIs that don't have, um, proper scoping or proper contract designs around them, um, can in, can inadvertently ex excessively expose data or send back much more data than is requested.

Um, and so if you have a good telemetry stream of APIs, you can actually then examine that and look at it and that can actually help reduce the excessive data exposure, which by the way is one of the top 10 risks. If you've been looking at the O OSP API top 10, you will see that excessive data exposure, it is pretty common and we've seen it a lot in the dataset as well. Um, great question.

I really appreciate that one coming in and just double checking. Okay. Looks like we don't have any additional questions coming in from the audience.

Um, so again, you know, hopefully this has been an informative session for anybody who is in the process of either, you know, embracing an API centric development model going forward or thinking about like, hey, we're going to be API centric in 2024. What are some of the risks that we need to be thinking about and maybe getting ahead of and how do we kind of position our organization for best success and let's say minimum security exposure or minimize the security risk around that API centric development. Um, hopefully this kind of puts some contextualization around the convergence of cloud and application security.

And uh, for anybody who is interested, I'm more than happy to take any follow up questions. Please do feel free to reach out to me anytime on email. Uh, again, my email address is there.

My name is Jeremy Snyder, I'm the founder and CEO of we would be more than happy to answer and help out in any way we can on your a team at Techron and SecOps 2024 live. It's my pleasure today. Thank very.