EP62 Protect Modern Applications in the Cloud: Union of APIs and Application Security

Security running.

Hi there. Welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your hosts here, as ever, are myself, Tim Peacock, the product manager for threat detection here at Google Cloud, and Anton Chuvakin, a reformed analyst and esteemed member of our cloud security team here at Google. You can find and subscribe to this podcast wherever you get your podcasts, as well as at our website, cloud.withgoogle.com/securitypodcast. If you like our content and want it delivered to you piping hot every Monday afternoon Pacific time, please do hit that subscribe button. You can follow the show and argue with your hosts on Twitter as well, twitter.com/cloudsecpodcast. Anton, this is a fun episode this week because not only are we talking about a topic near and dear to my heart, AppSec, specifically APIsec, specifically talking about automated abuse of APIs, but it also ties into one of my favorite events every year, which is the Security Summit. What is— before we get to the topic, what is the Security Summit, and why should all of our listeners check it out?

So Security Summit is kind of a virtual conference. I think it used to be in person before COVID but by now nobody remembers it. So it's a virtual conference with a bunch of really fun presentations by various Googlers and customers about various security innovations. There's a session on autonomic security. There's a session on a few other topics, encryption. And of course, there's a session on API security. Which is really fun.

What is API security? Isn't that just AppSec?

Ah, but it's a mysterious question. And well, in a few minutes, you'll hear our guest explain it. And I think he would mention that application security and API security are kind of forming a Venn diagram. AppSec is bigger than API security, but also API security is bigger than AppSec.

Okay. So you're going to try to do Venn diagrams over the air for our listeners. That makes a lot of sense to me. Listeners, once again, check out the Security Summit. You can find it online by searching for it, and we will include a link to it in our show materials so you can go register and watch all of the fun talks that all of the cool security professionals at Google are doing. And fun fact, these sessions have video. You don't just have to listen to our voices for them. And so with that plug in place for the fun thing that's happening this week, let's turn it over to today's guest. I'm delighted to introduce today's guest, Etienne de Burg, a senior security and compliance specialist here in Google Cloud's Office of the CISO. Etienne and I actually go way back. He was a user of mine a long time ago, so it's really fun to have him on the show today. Today we're talking about API security. Etienne, what's going on with API security? Why is it so hot today? Why is it a priority? And why wasn't it a priority 10 years ago? It's not as if APIs are somehow new.

new.

In fact, they weren't even new 10 years ago. So what's going on here?

Tim, that's a great question. And it's actually, I think, something that we do get asked fairly frequently by customers who kind of gone on a digital journey. So today, many firms are trying to increase the digitization of their systems and their assets. They're trying to reach out to consumers and partners using API calls. So they're just the sheer The volume of APIs in use, I think, has really increased a thousandfold in the last 10 years, probably more. So the need to understand how those APIs operate and how those APIs can be secured has really started to manifest much more greatly. It's just the changing business operations. People are using APIs to a far greater extent. So that's why there's such interest in API security. Because they're kind of the, almost like the window for many business offerings today, be it to the consumer or business-to-business. They're very much the storefront by which many people are offering services. So, that storefront needs to be secured, and that's really kind of driven a lot of the interest.

So, that means we kind of crossed a chasm of some sort in terms of volume of usage, because obviously securing, I don't know, AI is a priority today, but it's not a burning priority like securing APIs. So you're saying that we crossed some kind of chasm in terms of usage, and this is now a pervasive problem and not just an esoteric technical problem.

Very true, Anton. I mean, I haven't got the precise percentage, but the majority of internet traffic today is API traffic.

Whoa, whoa, whoa, hang on, hang on, hang on. The majority of internet traffic today is API traffic and not like video frames for Netflix and YouTube?

So a lot of that traffic is invoked via APIs.

API traffic.

Yeah, correct. So when that traffic is back-ended or you're talking to an API of some description. So I think this is, I can't remember if it's Gartner or some of the other, you know, our larger partners or commentators on the space, but the larger proportion of internet traffic now is driven by APIs.

Hmm.

Well, I don't want to dwell on this too much, but I feel like we could pick at this. I want to ask kind of a different question. How is API security different from application security? Isn't the first A in API just It is. Okay, good. I got that much right. How are they different?

Application program interfaces. And you're quite right. To build a secure API, I think you do need to have good application security practices. So that'll be understanding that your code is secure, that your software development lifecycle ends up with code that's free of bugs and vulnerabilities and any other kind of weaknesses. So absolutely. But APIs then are, you know, API security is taking what the code you've built, That's essentially allowing applications to talk to each other. So now you have to make sure that you understand, okay, can— is the communication path secure? Do you understand who's using those applications? So do you have like authentication in place? So you understand, is it Anton making a request or Etienne making a request or Timothy making a request, or an application is making that request on their behalf that they've already authenticated to? Do you understand that the authorization that they might have? Are they allowed to post something to a website? You know, are they allowed to add something to a website? Are they allowed to delete something from an application? So you start to need to understand what's the functionality that an API has? Are you permitted to use that functionality or not? Are there situations whereby there might be too many requests, say, to an application?

Mm-hmm.

So you need to understand, okay, is there a way I can filter out requests that are valid and I can drop or reject requests that are not valid? So the kind of other elements of application security that API security kind of brings into play, because it's kind of the usage and consumption of an application. It's not just looking at an application in a static way. We're now looking at the actual usage of an application and how one application might consume services from another application in a, say, in a B2B place, or from a frontend to a backend, or even a consumer might call a set of services to maybe provide a shopping basket with items in the shopping basket, with prices, et cetera. All those things might be separate. We're probably getting into a wider discussion about microservices. So you might have a monolithic service that might provide those things, or in a more modern application architecture, you might split out many functions into microservices, which are going to be one or a large number of APIs, which now need to be managed. and secured. And that complexity can get a little bit overwhelming if you have a very large number of microservices. You want to make sure there's consistency, you want to make sure that you can secure them all the same way. So you kind of need to think about, how can I do that at scale? How can I do that consistently across a range of applications and a range of this communication, application-to-application communication, that's facilitated via APIs?

I actually hear the answer in what you're saying because I think like if somebody's approaching API security as simply a subset of the 1990s application security, that you'd be very wrong. Because a lot of things like scaling, like application usage, but complex integration between multiple applications are not traditional AppSec topics. At least I'm not an AppSec expert. I'd be open to admit that. But to me, I don't see them show up in many traditional AppSec discussions.

Yeah.

So I think I hear a more crisp answer in your answer, is that it is kind of technically part of the application security, but it's not in the traditional AppSec core of knowledge perhaps.

Is it to AppSec what XDR is to AV?

Oh, no, no, no. You can't say XDR. I have to drink, Tim. Sorry. This is like a low blow.

No, I heard some really interesting things in there too, especially around the service mesh aspects of API security. That's a fascinating area these days.

Absolutely. And I think just to, I'd probably say application security is kind of a subset of API security. Maybe that's the way to consider it.

Interesting.

API security is kind of a broader—

Venn diagram. Would you agree to a Venn diagram? Yeah. There's AppSec that's not APIsec. There's APIsec that's not AppSec.

Listeners, you can't see this, but Anton is making Venn diagrams with his hands. It's very exciting.

But essentially, you know, AppSec would be how you might build components in code. how you might build the applications. API security is probably about around the consumption, might be the way to consider it, how you might consume those services. So it's kind of that broader view about the consumption of the services that you've built using your software development lifecycle. Maybe that's the way to consider it. Service meshes, again, as you related to, are kind of, again, another fascinating way to kind of get consistency and maybe ensure that developers have a more consistent and maybe more productive and easy way to deploy some of the security mechanisms that they might need to use. So you kind of try to make it easier for the developer by kind of placing some of those services in the service mesh or providing some form of API gateway that they can register their APIs with. So you're just trying to make it, again, easier in terms of that developer journey.

That does make sense. And I think that it makes for a perfect foray into our next question, which was about threats. In many cases, when people show up with security safeguards, I have API security, you have cloud security, Tim has XDR, unfortunately, You make it sound like a disease. No comment. The point is that the question of threats comes up. So I think one of the dimensions that you mentioned is that, of course, APIs are meant to be exposed, in most cases publicly, just like cloud computing. So what are the real threats to exposed APIs? Are we seeing incidents? Are we seeing automated attacks? Just give us a bit of a threat assessment on that that apply to a typical organization.

So now coming back to come over this idea, you know, it's your shop front, it's your storefront, you know, it's kind of the set of APIs. So in terms of the threats we're seeing, if you think about so many services that are now exposed via APIs, as you said, so each of those services is part now of your attack surface that a malicious party can seek to abuse in some way. So any API that you publish publicly, hopefully it's used by a valid customer, but it could also be abused by a malicious party. And we are seeing attacks, very different types of attacks in that kind of space. The most obvious one might be a denial of service attack against your API, so your valid consumers can't get the service. That could be volumetric, you know, it could be a DDoS attack, it could be just by drowning your API in requests that it can't deal with, the backend can't process. That's one type of a attack that is frequently seen. You can see other kind of abuse cases. So it might be that your competitors are trying to understand your pricing models. So they might be querying the APIs to get business advantage if you're not, or literally scrape all the information from your backend about your pricing model or other bits of your business logic or your business processes to help them understand how they might compete against you more. more effectively. And that's where you probably want to control who's accessing the API, how much information they can pull in a single request, the time it might take them to pull each of those pieces of information. A very long time ago, I think some airlines were comparing the pricing on seats and the capacity on each aircraft to understand how they might change their pricing via API calls to their competitors' web pages. I can't possibly suggest which airline or which part of the world that took place in, but there are situations where APIs APIs really can be misused.

I misused an API once in a pretty spectacular fashion. I was looking at the security on a number of American banks. I'll say it wasn't a foreign bank. And I was curious about their branch and ATM locator functions. And I discovered that a particular bank was more than happy to cough up several megabytes worth of geographic data on each request. I did not automate this attack, but I suspect very strongly that had I hit that at a greater than manual rate, it would have been a bad day for some poor SRE. So on that note of automation and hitting APIs and DoS, APIs are designed for automated use, not manual use. So how do you tell intended automation from abuse automation? Like, how do you tell the difference there?

So It can be difficult because it depends what the API is and what the API has been used for. So if the API is interfacing with a human being, then, you know, there's a certain pace at which a human being might, you know, enter a web form or request information. So if you start to use some logic to understand, okay, could the human being make this number of requests per second or per minute or whatever your timeframe might be, then you'll know that there is some form of automation taking place. There's a technique called scalping whereby a malicious party might pre-fill a web form with credit card credentials to get, say, tickets to a rock concert or to a football game much more quickly than a human being could possibly do so when those tickets go on sale. And you could understand if that request is a human or been automated by just by the timeframe in which they can complete that request. If they can make multiple requests in seconds, it's probably an automated attack because a human being won't be able to type that quickly to provide that type of information. Sort of the difference in terms of the usage patterns, in terms of, you know, the number of calls to the backend. That's how you can kind of get an understanding of it, you know, if it's automated or manual in terms of usage, if your API is that way based.

So it sounds like this isn't the only challenge with API security. It's not only about telling good bots from bad bots. Could you give us like a quick top 3 reasons why this is hard? Why we can't just write a short white paper that says, here's how you do API security, and everybody's like, okay, and they're done. So why is it hard?

So it's hard because if you think about the, really what APIs are, there are many, many different types of business logic on what you're trying to use the API for. Now, is it to do a transaction with a bank? Is it to buy flowers or, you know, buy something on a website? Is it internal communications between 2 backend systems within an enterprise? So the threat profile of an API might be different. What you want to achieve in the security outcomes for that API might be quite different as well. You might be concerned about confidentiality, you might be concerned about integrity or availability. Each of those things might cause you to make different decisions about what matters for your API. So there isn't really a one-hat-fits-all security model for each API. It depends what it's trying to achieve. It depends on its risk profile. You really have to think about, okay, what are you trying to achieve with this individual API itself? There isn't a one-hat-fits-all kind of scenario here. There's so many different business conditions or services that might be made available via an API. They're all so different. That's the challenge. The beauty and the challenge. Yeah, the APIs are so flexible, they can do so many different things, but the challenge is because they are so different, you have to think about protecting them in many different ways as well.

But is there a question of expertise as well? Like, who do you give the challenge of securing APIs? Do I Go for the appropriate person that focuses on application security? Do I have the network security challenge? Because some of this is DoS and consumption, and some of the business logic stuff should go to— I'm not sure to where. It's not really, strictly speaking, even AppSec. So how do you find talent to do API security? That's a kind of a bit from the left field question, but like, who should do API security? What type of people?

It's probably all of the above. That's the challenge. To do it properly, you really are probably thinking about people who have knowledge and understanding of all the facets that you outlined, AppSec, network security, and some of the business logic as well, because that will deal with some of the misuse or fraud conditions that could arise from the misuse of APIs, which is why it's difficult to get those things in one team. It's difficult to get those things in one place sometimes. So you really need to start thinking about, okay, is there a way I can bring some of the different skill sets together? I can bring those maybe into either a central team or a central place whereby I can apply an agreed set of policies that I need to, or an agreed set of capabilities that I need to deploy to protect my set of APIs. Because if you make it democratic and you split API security across all of your development teams? Do you understand that they have the expertise and knowledge to apply what you need them to do to secure a set of APIs? Or do you actually try to give them a framework in which they can almost delegate some of the responsibility for some of those API security features to a team that understands how to do that activity?

So on this theme of delegating security features, What do you actually need? What are the components of API security? Is it security operations theory? Is it actually like this, this, this, and this? Is there an OWASP top 10 of API security? What do we actually need here?

So there is actually an OWASP top 10.

No way.

For API security, which I would encourage you to go read. But the interesting thing is that, obviously, OWASP have top 10s for many things. But they really felt the need to have one for API security because it's so important in the digital economy. So they really wanted to make sure people could focus on the many different attack vectors that might exist so that teams could focus on what they might need to do to protect themselves. So, you know, we talked about the different components. You know, you need to understand some of the networking implementations, you know, things like TLS or SSL, whatever you want to call it, to understand how to secure communications. But also when you think about APIs, it might be you want to secure messages. You want to make sure that if someone is sending a message to an application, that the message itself can be verified that it's from Anton or from me or from you. I can read my messages, I can't read Anton's. So you need to start thinking about mechanisms that will allow you to not just secure the underlying transport mechanism, but actually some of the actual data that's being transmitted and ensure that only the right people can read those messages. And there are mechanisms to allow you to achieve that. There's message signing, there's use of web tokens, OAuth tokens to make sure that people are authorized the right way, they have the right authorization so they can read what they need to read and they can't read things that they can't, they've got no entitlement to read.

So what about things like threat detection? Do you think if I am looking at the components of API security, do I need some special focus on detecting threats to APIs? Is there API IDS? Or is there a way to detect threats through other means? And no, I don't mean XDR team.

No, but fun fact, I once wrote a patent for an API firewall.

Ah, so there are API gateways and proxies, uh, that are absolutely components that people can use to kind of, uh, to almost like front-end APIs. And it can be for a number of different reasons. It can be, you know, for management, it can be for performance, to reduce complexity, but also to add some security components as well, and make sure that you get standard security outcomes across each of the APIs that you publish. In terms of understanding if some— this is API threat detection. So some of those proxies can give you an understanding of API abuse. They can provide centralized logging so you can get an understanding of, okay, is a given IP address or a given external party continuously hitting my API? So I can start to do things like either send them somewhere else or send them different types of data so they can stop impacting my API. That centralized logging also means you can send it to machine learning systems to actually understand, okay, how are people consuming or abusing an API? How can I adjust? What might I need to adjust in my API in terms of maybe rate limiting or some of the backend functionality that the API exposes? Because an API might have different levels of authorization depending on who you are.

Yeah.

administrative interface, it might be a consumer interface. So you might want to understand, okay, someone continuously hitting my management API. Okay, do I— now I understand I'm under attack, are there any additional mechanisms I might need to undertake to protect that API? So things like machine learning, when you're starting to log all the calls, understand who's doing what and what they're trying to achieve, the gateways can really facilitate that kind of protection and allow some of those other more maybe intelligent services to kind of start to inform your decision-making.

That actually does make sense to me. And I think I like that it's, well, I don't want to sound too salesy, but there are technologies that can help you with detection, visibility, observing things, logging things in APIs. So to me, this does make sense. And maybe we are not at the, here's an API firewall, install it and you're secure. But then again, a normal firewall never did that. So it's reasonable. Now, To start with our final question before our real final question, I guess I should say penultimate, one thing I want to explore is the whole misconfiguration angle. When you look at cloud security, many of the podcast guests, many of the people in the industry would always point out that the biggest cloud security problem, notice I'm not saying risk or threat because I don't want to fall into the trap, biggest problem is misconfigurations. So is API the same? Is API misconfigurations...

Yeah.

Leading to security problems. Are APIs hard to configure securely for most organizations? So give us your view here if possible.

So if you think about the cloud, the cloud is, many of the cloud service providers, they provide you with a set of API calls. That's very much what a large proportion of the services are. But those organizations have thought about how to secure those services. They've got a solid understanding of how to manage, operate, and run, you know, a set of APIs at a global scale. So that's really what a lot of the CSPs are undertaking. When you start to think about APIs at an organizational level, so if I'm running a business, do I actually have an inventory of all my APIs? Do I actually know where all my APIs are? Are they automatically logged? Is there a repository for them? They're a business asset, but often they'll be left to a technology team to manage and operate. as opposed to maybe being part of an asset register that's providing very key business services. So that's kind of the first problem, understanding which APIs you actually own and possess. Then in terms of misconfigurations, yeah, if you don't understand who's using your APIs, so have you configured authentication and authorization for your APIs? Do you understand how to do that? So that's where you can end up with some of these problems. So a bad actor could start to use your API to maybe access information that they shouldn't access. They could, if you have a database, if you don't have, say, authentication, they could pull all the data in the database as opposed to only maybe only the records in the database that you want an individual to have access to. So there are absolute misconfigurations you can make. Without going too much into the complexities of some of the technology, you might allow APIs to make thousands of calls maybe to your backend mainframe. And maybe that system can't handle that volume of requests. So a frontend system that's accessible across the internet could actually cause you an internal DoS situation on a backend system because you haven't thought about, okay, what mechanisms or protections can I put in place to make sure that I can't, you know, a backend system doesn't get flooded with requests it can't handle. So there are absolutely, you know, misconfiguration scenarios that you need to consider.

Got it. Okay. Well, Etienne, it's time to wrap up. Do we have one tip for improving API security and perhaps some recommended reading so we don't leave our listeners empty-handed?

So the recommended reading would definitely be that OWASP Top 10 API Security that you mentioned earlier. I think that is very much essential reading.

For the record, I didn't know it existed, so I was being facetious. I'm delighted that the industry continues on in ways that are intuitively understandable.

And in terms of one recommendation, I think it would be, if you haven't got an inventory of APIs, start that process now.

Hmm.

If you haven't got a centralized team or function looking at API security, start to consider putting that in place now. And if you're running thousands of APIs, consider something like a scalable API gateway of some description, because that will save you a lot of pain. later down the road. If you do that early, you'll save yourself a lot of cost, a lot of security concern, and a lot of angst further down the road.

Well, Etienne, thank you so much for joining us today. I think that is all we've got time for.

Thanks, Timothy. Thanks, Anton.

And now we are at time. Thank you very much for listening, and of course for subscribing. You can find this podcast at Google Podcasts, Apple Podcasts, Spotify, or wherever else you get your podcasts. Also, you can find us at our website cloud.withgoogle.com/cloudsecurity/podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter, twitter.com/cloudsecpodcast. Your hosts are also on Twitter at Anton_Chuvaikin and Tim_Pico. Tweet at us, email us, argue with us, and if you like or hate what we hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.

Ssssss— Security!