Do you have something cool to share? Some questions? Let us know:
TIM PEACOCK: Hi there, welcome to the Cloud Security Podcast by Google. Thanks for joining us today. Your host 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/cloud security / podcast. 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. And this is a fun episode this week, because not only are we talking about a topic near and dear to my heart, AppSec, specifically API sec, specifically talking about automated abuse of API's. But it also ties into one of my favourite 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?
ANTON CHUVAKIN: 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 not only on security, there's session on a few other topics encryption. And of course, there's a session on API security, which is really fun.
TIM PEACOCK: What is API security? Isn't that just AppSec?
ANTON CHUVAKIN: Ah, but it's a mysterious question. And well, in a few minutes, you'll hear our guests 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.
TIM PEACOCK: Okay, so you're gonna 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 Burgh, a Senior Security and Compliance Specialist here in Google Clouds 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. In fact, they weren't even new 10 years ago, so what's going on here?
ETIENNE DE BURG: So, that's a great question. And it's actually, I think something that we do get asked fairly frequently by customers who kind of going on a digital journey. So today, many firms are trying to increase the digitalization of their systems and their assets, they're trying to reach out to consumers and partners using API calls. So, that just the sheer volume of APIs in use, I think, has really increased 1000s folds in the last 10 years or probably more. So that the need to understand how those APIs operate, and how those API's can be secured, is really starting 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, not be it to the consumer or business to business. They're very much the storefront by which many people are offering services. So now that storefront needs to be secured. And that's really kind of driven a lot of the interest.
ANTON CHUVAKIN: So that means we've kind of crossed the 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 API's. So, you're saying that we crossed some kind of chasm in terms of usage. And this is now a pervasive problem and not necessary a technical problem?
ETIENNE DE BURG: Very sure Anton. I mean, I haven't got the precise percentage, but the majority of internet traffic today is API traffic.
TIM PEACOCK: Oh, 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?
ETIENNE DE BURG: So, a lot of that traffic is invoked via API's.
ANTON CHUVAKIN: API traffic, yeah, correct.
ETIENNE DE BURG: So, when that traffic is back indeed which you’re talking to an API some of the description. So, I think this is a common if it's Gartner or some of the other, a larger partners or commentators on the space, but the larger proportion of internet traffic now is driven by API's.
TIM PEACOCK: I don't wanna dwell on this too much, but I feel like we could pick this. I wanna ask kind of a different question. How is API security different from application security isn't the first A in API just application?
ETIENNE DE BURG: It is.
TIM PEACOCK: Okay, good. I got that much, right. How are they different?
ETIENNE DE BURG: 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, it'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 kinds of weaknesses. So absolutely. But APIs then are API security's 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 that be 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 request? Or an application is making a 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 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? 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, they're kind of other elements of application security that API security kind of brings into play, 'cause 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 inside a b2b place or from a front end to a back end. 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. 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 gonna be a one or a large number of API's, 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 can manage the cloud how can I do that at scale? How can I do that consistently across a range of applications and a range of this communication applications replication communication, now that's facilitated via API's?
ANTON CHUVAKIN: I actually hear the answer in what you're saying because I feel like if somebody is 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 is 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. So, I think I hear 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.
TIM PEACOCK: Is it to AppSec what XDR is to AV like--
ANTON CHUVAKIN: Oh, no, no, no, you can't say XDR I have to drink tea, I'm sorry, this is like a low blow.
TIM PEACOCK: 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.
ETIENNE DE BURG: Absolutely, I think just to probably say, application security is kind of a subset of API security, maybe that's the way to consider it. API security is kind of a broader--
ANTON CHUVAKIN: Venn diagram, would you agree to a Venn diagram?
TIM PEACOCK: Yeah.
ANTON CHUVAKIN: There's AppSec that's not API sec, there's API sec that's not AppSec.
TIM PEACOCK: Listeners, you can't see this. But Anton is making Venn diagrams with his hands, it's very exciting.
ETIENNE DE BURG: But essentially, you know, AppSec would be how you might build components encode. 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 theirs that broader view about the consumption of the services that you've built using your software lifecycle, maybe that's the other way to consider it. Service meshes, again, as you related to a 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 tried 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 out there, sort of API's where so you just want to make it again, easier for you in terms of that developer journey.
ANTON CHUVAKIN: That does make sense. And I think that it makes for a perfect for 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. There's a question.
TIM PEACOCK: You make it sound like a disease.
[LAUGHS]
ANTON CHUVAKIN: Not common. The point is that the question of threats comes up. So, I think one of the they mentioned 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 expose the API's, obviously, an incidence? Are we seeing automated attacks, just give us a bit of a threat assessment on that, that apply to a typical organization?
ETIENNE DE BURG: So, when I come back to come up with this idea, your shopfront is your storefront. No, it's kind of a 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 back end can't process. That's one type of 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 literally scrape all the information from your back end about your pricing model or other sort of other bits of your business logic or your business processes to help them understand how they might compete with against you 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. Can't possibly suggest which airline or which part as well, that took place in. But there are situations where API's really can be misused.
TIM PEACOCK: 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 SRA. 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?
ETIENNE DE BURG: So, it can be difficult ‘cause 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 enter a webform or request information. So, if you start to use some logic to understand, okay, could be human being make this number of requests per second or per minute, or whatever your time frame might be, then you will know that there is some form of automation taking place. There's a technical 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 tickets go on sale. And you can understand if that request is a human or been automated by just by the timeframe in which they can complete that request. That if they can make multiple requests, in seconds, it's probably an automated attack. 'Cause a human being would better type that quickly to provide that type of information. You saw the difference in terms of the usage patterns in terms of the number of calls to the back end. That's how you can kind of get an understanding of if it's automated or manual, in terms of usage if you're a price that way based.
ANTON CHUVAKIN: So, it sounds like this isn't the only challenge with API security. It's not only about tearing good bots from bad bots. Can you give us like a quick top three 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?
ETIENNE DE BURG: So, it's hard because if you think about the really what APIs are, there 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 buy something in a website? Is it internal communications between two back-end 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, the reason really are one half fits all. Security model for each API depends on what it's trying to achieve, it depends on its risk profile. You really have to think about, okay, what you're trying to achieve with this individual API itself. There isn't a one half fits all kind of scenario here. There's so many different business conditions or services that might be made available via an API, they've also different that's the challenge. The beauty and the challenge here that APIs are so flexible, they can do so many different things. But the challenge is 'cause they are so different; you have to think about protecting them in many different ways as well.
ANTON CHUVAKIN: But is there a question of expertise as well? Like, who do you give the challenge of securing API's? Do I go for the appropriate person that focuses on application security? Do I have the network security challenge, because some of this is Dawson consumption? And some of the business logic stuff should go to I'm not sure who to where it's not really strictly speaking of an AppSec. So, how do you find talent to do API security? It's a kind of a bit from the left field question, but like, who should do API security, what type of people?
ETIENNE DE BURG: 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, you know, AppSec network security, and some of the business logic as well, ‘cause that will deal with some of the misuse or fraud conditions that could arise from sort of misuse of API's. 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 it and agree to have policies that I need to or agree to have 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 there, 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.
TIM PEACOCK: So, on this theme of delegating security features, what do you actually need? What are the components of API security? Is that security operations theory? Is that actually like this, this, this and this? Is there an OWASP, top 10 of API security? What do we actually need here?
ETIENNE DE BURG: So, there is actually an OWASP, top 10.
ANTON CHUVAKIN: No way.
ETIENNE DE BURG: For API security, which I would encourage you to go read. And but the interesting thing is they always have top 10 for many things. But they really felt the need to have one for API security, 'cause 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 now, we talked about the different components, you know, you need to understand some of the networking implementations and things like TLS, or SSL, we want to call it, to answer how secure communications. But also, when you think about API's, 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. So, you need to start thinking about, mechanisms that 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 in as message signings, use of web tokens, or tokens to make sure that people are authorized the right way. They have the right authorization to, so they can read what they need to read and they can't read things that they can't, they've got no title to read.
ANTON CHUKAVIN: So, what about things like threat detection, do you think if I'm looking at the components of API security do I need some special focus on detecting threats to API's is their API IDS or is there a way to detect threats through other means and no, I don't need XDR team?
ETIENNE DE BURG: No, but in fact, I once wrote a patent for an API firewall, so the raw API gateways and proxies, they’re absolutely components that people can use to kind of to almost like front end API's. And it can be for a number different reasons it can be 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 API's that you publish. In terms of understanding if some issues 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 server 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 of they can stop that, you know, impacting my API. That centralized logging also means you can send it to machine learning systems to actually understand like, how are people consuming or abusing an API. How can I just 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. It might be administrative interface; it might be a consumer interface. So, you might want to understand, okay, someone continuously hitting my management API. Okay, what 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 trying to log all the calls, understand who's doing what, what they're trying to achieve. The gateways can really facilitate that kind of protection, and allow some of those other, more maybe intelligence services to kind of start to inform your decision making.
ANTON CHUKAVIN: That actually does make sense to me. And I think I like that it's, well, I don't wanna sound too salesy, but there are technologies that can help you with objection visibility, observing things, login things in API's. So, to me, this does make sense. And maybe we are not at the here's an API firewall installed and you are secure. But then again, a normal firewall never did that. So, it's reasonable.
[LAUGHS]
Now, to start with our final question before our real final question, I guess I should say at the melting point, one thing I wanna here 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, leading to security problems? Are API's hard to configure security from authorizations? So, give us your view here, if possible.
ETIENNE DE BURG: So, you think about the cloud, the cloud is many of the cloud service providers, they provide you that 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 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 API's? Do I actually know where all my APIs are? Are they automatically logged? Is there a repository for them? They were a business asset but often there'll be left to a technology team to manage and operate, as opposed to maybe being part of an asset register. But that's providing very key business services. So that's kind of the first problem understanding which API's you actually own and possess. Then in terms of misconfigurations, yeah, if you don't understand who's using your API's. So, have you configured authentication and authorization for your API's? 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 so 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 absolutely 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 back-end mainframe, and maybe that system can't handle that volume of requests. So, a front-end system that's accessible across the Internet could actually cause you an internal dos situation on a back-end system because you haven't thought about okay, what mechanisms are protections can I put in place to make sure that I can't you know, back-end systems doesn't get flooded with requests it can't handle. So, there are absolutely no misconfigurations scenarios that you need to consider.
TIM PEACOCK: Got it. Okay, well, at the end, 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.
ETIENNE DE BURG: 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.
TIM PEACOCK: 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.
ETIENNE DE BURG: And in terms of one recommendation, I think it would be if you hadn't got an inventory of API's start that process now. If you hadn'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 API's, 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 will save yourself a lot of cost, a lot of security concern and a lot of angst further down the road.
TIM PEACOCK: Well, that's the end, thank you so much for joining us today. I think that is all we've got time for.
ETIENNE DE BURG: Thanks Timothy, thanks Anton.
ANTON CHUKAVIN: And now we are 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 podcast. Also, you can find us at our website cloud.google.com/cloudsecurity/ podcast. Please subscribe so that you don't miss episodes. You can follow us on Twitter, twitter.com/cloud sec podcast. Your hosts are also on Twitter at anton_chukavin, _TimPeacock. Tweeted us, email us, argue with us and if you like or hate what you hear, we can invite you to the next episode. See you on the next Cloud Security Podcast episode.