The State of API Security- 2023 Webinar

Jeremy

‍

Thank you so much for joining us here today, I really do hope we have some time for some great conversation and I really do look forward to questions at the end so please do pop those in as we go.

‍

A couple quick words about myself I've been working in technology broadly speaking and kind of cyber security and IT for about 25 years now and really I've spent my career in kind of two distinct phases phase one being a practitioner of cyber security and IT for 3 startups over about a 13-year period in phase two when I kind of transitioned to the other side of the table working more let's say on the vendor and provider side first with AWS and then with a number of other companies in kind of the Cloud and cyber security ecosystem. 

‍

And really the work that we've done here at FireTail is kind of the culmination of all of the work over that 25-year career It's a combination of some of the technology trends that we've observed and some of the things that I've seen with customers that I've worked with over the last 12 13 years in their own evolution is how they've transitioned into the cloud and then how they've gone from what I kind of think of as Cloud 1.0 to Cloud 2.0, Cloud 1.0 really being kind of that early let's say the early 2010s phase of Cloud adoption into more of let's say the late 20 teens and early 2020s phase of kind of refactoring and changing architectures to become more Cloud native embracing things like microservice architectures and so on.

‍

And time permitting we’ll go into a little bit of that but I think the the real reality of where we are today is what we should focus on and that is kind of the current state of APIs in the internet that we all know use love and depend on for so many things in our day-to-day lives. And the truth of the matter is as we're all probably sort of aware but maybe we don't explicitly think about is that APIs are really everywhere powering every aspect of what we do in our daily lives and powering the broader internet right here you've got kind of a little bit of a basic diagram but I want to try to make it a little bit more concrete by going through a few examples and before we do that I want to share some statistics that we've gathered over the last few years and I certainly can't claim credit for all of this analysis I'll try to cite sources and please, you know just ask if there's anything that you want to know more about, but I think one thing to start off with is this is a stat actually from a couple of years ago so I imagine the number has even increased but 83% of all web requests are API calls. And I know that number sounds really crazy when we think about how we're using the web and how most of us in our day-to-day lives are using things like Google Docs or we're using our email or we're using any number of other systems and we don't think about making API calls or making API requests as we use those systems but really APIs have become the building block of the modern internet.

‍

I like to tell people one way that you can kind of think about that is next time you're loading a page on your web browser pay attention to the little status bar down at the bottom and you'll note that there's a number of third-party sites that are being loaded in addition to what you're actually loading so you might be reading a story let's say on CNN or BBC News and in the background BBC or CNN is calling in four or five other external services to kind of create that page that you're reading all of that is more kind of concrete real world examples of API calls in action.

‍

And another example that I really get a lot of pleasure out of kind of explaining to people and trying to make it more relatable in our daily lives is mobile food delivery. About seven, eight months ago I sat down with a friend of mine who works at one of these mobile food delivery companies and we started analyzing this question that I had which is you know every time I order food via let's say UberEats in my case being in the States but maybe it's Just Eat if you're in the UK or Deliveroo or Fedora or who knows what the service is called in your part of the world but I'm sure all of you are familiar with the kind of concept of ordering mobile food delivery by a mobile app. So I asked the question of my friend how many API calls go into a single transaction and we started kind of mapping it out you know from the point where I pull out my phone and I open the app and the phone picks up my geolocation and sent that to a back-end service that then uh based on my geolocation fetches a list of restaurants and then their menus to present to me in order to show me what food is available for me to order we kind of calculated okay just starting off that part of the request we've got kind of the location and the menu presentation we've already got about three to five API calls then and then from the time that I started actually you know selecting the dishes on my order I submit the order along with my payment payment information we get into a second wave of complexity we've got an additional five to ten API calls that are happening but we're also bringing in multiple third parties and we're sending very sensitive critical data from party a to party B so just think about the fact that you know I may be submitting my order to to a company like Uber or UberEats and they're sending my payment credentials off to a third-party provider like stripe or Square or somebody like that and in addition to that my order is now being sent to the restaurant the delivery service is being coordinated in order to kind of figure out who's available to make that delivery who's located in that area who can take the request on etc etc so as my friend and I were kind of mapping this out we started kind of making a tally we got to about 25 API calls we said listen there's more coming but this is ridiculous there's just so many and I think that's the way that I like everybody to think about this in the sense of you know how critical apis are so this is one business transaction 25 API calls at least three services and three vendors that we're coordinating with very sensitive information being sent payment credentials my name my profile my home address or my delivery address my phone number my email address, etc., all of this PII in addition to you know again my credit card details, etc. being sent around all over API calls and that is again how the modern web works if you are a company like one of these food delivery services it doesn't make sense for you to build all of these third-party services instead you kind of pull them in this building block to stitch together the flow of business transactions that you need to happen or the flow of business logic that you need to power that transaction.

‍

That's why I say you know APIs are actually the modern kind of call them the duct tape or I like to call it the connective tissue of the modern internet that we all use today so where are we in addition to this kind of 83 percent of all web requests being API calls we're actually on course to having a trillion programmable endpoints now this is a quote that comes from an analyst who's been studying the space for a number of years and it really kind of dovetails with that kind of Cloud 1.0 to Cloud 2.0 transition that I mentioned the momentum behind containers and serverless and multi-cloud and so on is just bringing more and more APIs and you know my

co-founder Riley and I we really observed this in our own day-to-day life before we started FireTail we were seeing this shift away from kind of legacy architectures and into more micro service architectures and we realized that no matter what you're doing APIs become that common thread for every data set or every business logic or every kind of functional transaction capability that you present it will be represented by an API sitting on a network that is available to be called and consumed and that's that's really where we are so hopefully that's all clear and give some context sets to what the modern internet looks like from an API perspective and why this is also critical.

‍

So just to kind of wrap up with a couple more stats you know we are probably around 200 million APIs across the web right now that's in terms of API Services um growing to 1.7 billion in 2030.

‍

When you think about the ratio of the APIs to endpoints that's where you can kind of see that that previous number kind of click into focus a little bit. One interesting observation is that private APIs are actually going to outstrip public APIs. So what does that mean? That means that, you know, if I am a company and I present something like the FireTail API that is available for our customers to consume behind the scenes, the FireTail API is probably communicating with 10 other APIs that make the FireTail service possible.

‍

One interesting stat that I saw recently is that over 62 percent of developers reported that they rely on APIs more in 2022 than they do in 2021. Why this was particularly interesting for me is what was happening during 2021 and 2022? We were kind of in the let's call it the later stage of coming out of the pandemic or in the process of coming out of the pandemic and what did we see during the pandemic? We saw massive scale digital transformation, you know, digital enablement of business transactions that we had never seen before and what you see is hey what's going hand in hand with that digital transformation? More and more API development, more and more API consumption.

‍

So what are the challenges that all of this API kind of transformation brings or poses to us so the first one is that you know when we sat down and we started analyzing all of the API data breaches that we observed or that we could find documented we realized that traditional security really wasn't going to work we'll get into why in just a couple minutes.

But let's talk for a second about what are some of the factors behind that. So number one is as we see more and more APIs being launched and we talk to developers and you can look at a number of devops surveys in Cloud professional surveys what you see is that developers are empowered to launch services directly there are generally very few gating mechanisms that keep developers from putting new APIs into service so what do you what do you get as a result of that? You get something called the API sprawl. 

‍

API sprawl or sometimes you'll hear things like Shadow APIs generally refers to one of two conditions. Number one is is that you've got multiple APIs serving the same function but because there's no centralization of API capabilities you have multiple APIs presenting either a data set or a business capability out to the world and number two is you have APIs that things like the IT or cyber security team are not knowledgeable of so they don't know that these APIs exist that presents great opportunities for attackers because they can find APIs that are not being secured why because nobody knows about them and of course that actually has proven to be the case.

‍

So API attacks have grown massively over the last couple of years I know this stat from 2021 is a little bit dated now but we did see just a massive rise in API attacks and API data breaches and in late stage 2021 our own data shows that this trend has actually just continued. We've seen close to a billion records being breached or at risk of breach and one of the interesting conclusions that was not ours but is actually quoted and attributed to somebody else is that its vulnerabilities and apps handling the API data are the direct cause of those breaches nothing else is to blame so even if you potentially had traditional let's say network security or perimeter security in place, these API breaches continue to happen.

‍

There was a good CISO survey done a little while ago around APIs and the question was really hey what are some of the challenges that you see around APIs and of course the number one response that came back was the lack of API inventory and just as we talked about a second ago the whole rise of API sprawl is really kind of behind that perimeter security is definitely a concern end-to-end tracing of code to API is one of the biggest things that we've heard from our customers as well as from the CISO survey is hey if we have an API that gets breached one of the challenges we have is that mapping that API back to the application code from once the API came to try to understand you know what was at fault in this breach so there's a couple other things there but those were some of the key ones that I wanted to talk about for a second.

‍

So let's dive into the data and let's talk about what we actually learned from our own analysis of API breaches over the last 10 years. So first before we actually get into some of the stats I did want to take a second to talk about what how we examined this or how we undertook this research. First thing to state is a couple of caveats, number one is we did our research only on

publicly disclosed API breaches if there are API breaches that were communicated to us in confidentiality if we didn't get permission from the other party to include them in the research we did not do that so this is primarily based on publicly available data so what you might think of as open source intelligence in terms of breaches and the analysis of those breaches in a few cases we did speak directly to the researchers who uncovered the breaches in order to get a deeper understanding of exactly what what happened in those cases but by and large we're relying on publicly disclosed data so of course there are breaches that are not included if they weren't publicly disclosed there may also be categorization of breaches into categories based on what was presented in the analysis or by the researchers so high level.

‍

Number one thing so I mentioned a minute ago that close to a billion records were breached or at risk of breach and one thing that you'll immediately see here is that we're actually disclosing 577 million records breached those two numbers obviously don't match the billion number includes responsible disclosures from cyber security researchers who reported the vulnerability to the companies owning the APIs who then managed to patch or fix the vulnerability before it was exploited in the wild so that's where you see the disconnect between those two numbers but let's just pause for a second to appreciate that number so 577 million records when we go through some of these breach examples you probably will find yourself thinking that some of them are very similar to services that you consume yourself and it's entirely possible that your data has been included in at least one of these API breaches over the years second thing to understand 13 million records per breach event.

‍

Now, I've been in cybersecurity for a while and I can tell you that that's a very high number for breach event and when we started to think about this and we started to kind of ask ourselves why is that number so high we realized it's because API breaches tend to be logical and they tend to be systematic so what does that mean that means if a flaw exists in an API it doesn't

disclose or it doesn't put out risk of breach certain records it puts entire data sets or entire business functions at risk so if you find a vulnerability in an API you can generally extract an entire data set where you can generally kind of manipulate the vulnerability to give you all the data sitting behind the API or potentially trigger the API into some kind of malicious activity to your own benefit.

‍

So when you average that out what you see is you see 43 unique documented breach events over the years and what we've done secondarily is we've taken all of the information to try to break it down into a few categories to understand what are the primary risks what are the primary attack vectors and you know if we're building an API today what are the things that we need to think about in order to make sure that we're shipping a secure API so number one the top two categories by a pretty wide margin for primary attack vectors are authentication and

authorization.

‍

Let's take a second to talk about what that actually means authentication is the practice of establishing who is using this API right so the easiest way to think about it is you know who is trying to use this is it Jeremy how do I establish Jeremy's identity that can be through some set of credentials often that's something like an API key or a set of you know let's say two credentials a key and a secret key so like a public and private key or something like an API key plus a certificate, etc., but it's a way of establishing the identity of the person consuming the API. 

‍

We’ll talk about a couple of the example cases in just a second about what are some of the common problems with authentication but authentication tends to be the number one or has been the number one in terms of the number of breach events. Second authorization authentication and authorization often get kind of confused because they are related concepts but they are different things from a cyber security perspective authentication as we just discussed is the practice of establishing who is using the API authorization is the practice of establishing what is that person allowed to do. 

‍

An example I like to use here is if you think about something like a social media app everybody on that app probably has a profile so I have my profile Alan has his profile, etc. If we're standard users I may have the permission to edit my own profile but I only have the permission to edit or

sorry to view Alan's profile if Alan's an administrator he may have the right to view and edit both his profile and mine so when we think about authorization we're often thinking about kind of three things together who is making the request what is the data that they're trying to access and what are they trying to do with that data are they just trying to view that data maybe that's allowed to every user are they trying to edit that data maybe that's only allowed to the owner of the data or to administrators but not to other users. 

‍

So the authorization question is a little bit of a trickier one and you will see that it definitely comes into play a lot of the breach examples that we're going to talk about and certainly in the broadest sense now we not only analyze the primary attack vector but we also analyze the number of records breached by category and so here again we see that authentication has actually been at fault in more than half of all data records exposed authorization surprisingly cuts down quite a bit on this side but it is still one of the factors at risk in a number of things.

‍

Configuration and data exposure actually are pretty broad risks as well, injection doesn't take a lot of the breach event but actually is at or is one of the ways that a lot of data was extracted in some of the cases overall governance is one of the things we're going to talk about in just a second but it generally kind of is a category that captures things like network configuration visibility etc. around APIs so you'll see a little bit of a difference between the primary attack vector and the number of events and then the primary attack vector in the number of records breached so some breaches are let's say like more impactful than others is one way that you can kind of interpret that data.

‍

But one of the most interesting things that we saw as well when we analyzed across all of these breach events is that pretty much all breach events are multi-vector what that really means in simplest terms is more than one thing went wrong right so you know at least two things were bad in this situation. So we also analyzed the secondary root cause from all of those things and we can see that you know again authentication and authorization are pretty big players but there we start to see things like data exposure and governance take a little bit more prominence in the analysis so let's talk about a couple examples and we'll go through them in some level of detail again based on what we are able to learn about them.

‍

I think one of the things that a lot of people think is that yeah yeah maybe you know some startups make these mistakes maybe some you know smaller companies, smbs, mid-market companies make these mistakes but actually the truth of the matter is even really big Brands large companies are at risk of API breaches so Peloton has actually been in the news just again recently we were just chatting with somebody earlier this morning in fact about another set of concerned drowns and Peloton APIs going back for a second to the example that I gave of the mobile food delivery app and how many APIs and API calls are involved in that actually every smart home device is also using apis there's not that much happening on the device itself there's a lot of data transfer between the device and some cloud service but quite a lot of that is and in fact you know probably 99.9 percent of that is done over API communication between the device and some cloud service at the back end so a couple of years ago there was a disclosure of a breach event around in Peloton APIs basically connecting the the bicycles to the Peloton backend API service.

‍

So what happened here- so first of all, the researcher tried to understand the Peloton APIs and if you've got any kind of connected device at home it's not actually hard to find the backend API service you can go onto your Wi-Fi router which does log all of the web traffic in your house and you'll actually see your device connecting to its Cloud service and the API calls that it's making. So based on that you can actually extract the API address or the URL of the API you can

see the format of API calls that are being sent to that back end and then you can actually try to manipulate it if you are so inclined so what this user found or sorry what this researcher found was that their profile ID in the API call matched their user ID that they were able to see so then they tried saying well if my let's say my user ID is one of my profile IDs, what happens if I change the profile ID I'm requesting to two to three to four so sequential numbering in API or in data record sitting behind apis is a really really bad practice it makes scraping very very easy and that was exactly the case in the case of Peloton. 

‍

The second thing that this researcher discovered was that once he was able to or once it was connected to the Peloton API service subsequent calls after the initial connection were not checked for authorization so an initial kind of attempt to connect yes it did need to verify the credentials of the user uh consuming the API service but every follow-up call didn't get rechecked so again authentication and authorization not the same thing they need to be performed on every single API call and that is one of the challenges around APIs and what you actually can kind of infer from this is the requests to scrape this data actually look like normal API requests there was nothing let's say in the fact of where the user was requesting from

that could have been blocked by a traditional firewall or something like that so again vulnerabilities in the applications handling the data are the direct cause of these breaches.

‍

The next example I want to cite is Lemonade which is a online insurance brokerage service and here we see a really clear-cut example of kind of two things going wrong number one was through a set of configuration changes on the network side the API itself including some of the data that it served got indexed by the Google bot and so you know of course one good practice around APIs is to prevent any kind of Bot traffic to the API Bots are known for kind of sending weird stuff to API services and if they get responses they will actually do things like index that response so this bot index laminated API the API actually starts to show up in the serp which is the search engine results page the API did not require authentication or check for authorization and it actually allowed for read write functions now this is a couple of years ago certainly this has been fixed since then but what you see is a combination of a network configuration error plus poor API design practices that led to this breach.

‍

So again just to kind of reiterate pretty much every API breach that we've tracked and analyzed has had multiple things go wrong with it then the next one I want to talk about is Starbucks so Starbucks was a really interesting case thankfully this one was actually fully a disclosure event and not an actual breach but some really interesting findings that were published and made public. 

‍

So number one is that the server configuration of the server that actually holds the API

exposed routes so what this means is I as somebody consuming the API could just send any random set of strings to the API and I would get error messages that would tell me what the structure of the API looked like so overly verbose error messaging is actually a common problem on APIs as it is with many web server technologies it's something that's very often done in kind of development environments in order to help developers build let's say services to consume APIs but then really needs to be turned off when you get into production and that was not the case here but through that kind of enumeration practice the researcher was able to discover a graphql endpoint that was not documented.

‍

GraphQL is a really interesting API technology that we won't really have time to get into in today's webinar but the GraphQL endpoint allowed the effective equivalent of a select star statement that allowed for the extraction of the entire data set so again we see here kind of poor server configuration around let's say the error messaging or maybe the server configuration between development and production we had a non-declarative API model that allowed for really a query of any data any level of data through a through a GraphQL database just a little side note there's a number of Open Source tools that you could find if you're ever playing around with graphql and you want to understand how easy it is to discover entire GraphQL data sets there's any number of tools that you can find out there open source.

‍

But excessive data exposure really led to a lot of the challenges around here so here you can see this quote the internal API had an exposed Microsoft block blah blah which would have allowed an attacker to exfiltrate 100 million user records including all that pii then last but not least there was a relatively recent I think it was September of last year breached by one of the major telcos in Australia called Optus and here what we see is kind of a common challenge for a lot of customers a lot of companies with their APIs.

‍

The challenge I want to talk about is basically the rate of change in Cloud environments so what you see here is you know kind of again with that shift from cloud 1.0 to Cloud 2.0 getting into more modern Cloud uh Cloud native or Cloud Centric architectures you see rapidly changing environments and one change made by one team to a network configuration made a private API public right so one little network configuration change turn this API into a public service this API had poor authentication again primary breach Vector again incremental account IDs and so you see a couple things coming together to expose data sets and you know from the person who extracted the data and posted on the dark web no authenticate needed all open to internet for anyone to use so that kind of presents the problem I think in a very succinct if grammatically poor way.

‍

So just a couple kind of final thoughts around this um one of the questions we often get around this is well okay what about me you know I work in such and such is this really a problem for me or for my industry one thing you'll notice from the examples we cited that's across many geographies so not really geography specific APIs really are everywhere if you're using an internet service chances are very very high about APIs are probably involved um some industries have had let's say over representation in the data set.

‍

And if you take a step back and you think about it they're actually industries that make a lot of sense technology software of course right why because software is always evolving and embracing the most modern architectures and so on manufacturing, automotive in particular has showed up in pretty high numbers in the last couple of years in particular and again if you zoom out and you think about well why would that be number one supply chains uh automobile

manufacturing is very heavily linked between third parties this is contract manufacturers of everything from seats to panels to embedded Smart Systems and that's the number two trend cars are becoming connected cars and those connected car devices are effectively IOT devices that talk over APIs to some back end service and so we've seen a number of things around that as well.

‍

And then hospitality so we see in the hospitality industry you think about let's say airlines travel hotels rental cars, etc. these are very connected services a lot of the booking that happens on that side is usually happening through third-party connected services again connected over APIs you might book through Kayak, Orbits, Expedia, Booking.com, etc to any number of airlines, hotel chains, etc., all of that kind of transaction processing is made possible by APIs. 

‍

So let's talk for a few seconds about effective API security I think one of the most interesting things that we've observed in our own work with CISOs and with our own customers is actually the things that they're looking for are really in direct response to that CISO survey you know really they're looking for the way to get visibility over their APIs they're looking for a way to observe those APIs and assess them against good security practices so what we see actually is you know if you combine kind of these six goals that we mentioned here (discovery, visibility, observability, enforcement policy and audit) if you combine them with an adoption path that aligns to how the technology is being rolled out in your organization and you focus first and foremost on getting visibility over your APIs through discovering an inventory process you automate that you make that an ongoing process and then your second step becomes kind of comparing the observed APIs to a policy in order to assess the risk and then prioritize which ones are the highest risk which ones are exposing the most PII Etc and you apply attack prevention first and foremost there and you make sure that you're auditing everything that's one of the successful implementation paths that we've seen around API security.

‍

One last comment on that is you know I mentioned earlier that traditional security approaches especially things like network security don't really work we really encourage companies to think

about where the risk where the risk is based on the attack vector research that we've done and also where it is based on technology so we did an analysis of log files from AWS and we tried to

understand you know if you think about what's gone wrong in these cases what visibility do you need to have over what data in order to understand if you've either been breached or if you're at risk of breach and you see things like authentication and authorization being so critical well if you look at normal network logs you don't get visibility over any of that if you look at API gateways you get things like authentication headers but you don't get visibility into let's say arguments or request parameters or into things like the response payload of what data is being sent back so you don't actually know what data has been breached or exposed in your systems only you only get that through application station logs or through logs that sit you know or come from the application level.

‍

And with that Alan I think that is a good place for me to stop on the presentation side and hopefully we've still got some time left for some questions from the audience.

‍

Alan

‍

That was excellent. Thank you very much Jeremy. So, just to reiterate for anyone who joined late and wants to ask a question you can send me a direct message on the chat I have a couple

coming in here already um so I will start with this one from Lina, um if we feel like we've covered all the security basics that you mentioned what's next?

‍

Jeremy

‍

Yeah, great question. I mean first of all if you've covered all the basics kudos to you you're well ahead of the game and you know you should be applauded for your efforts there but really kind of two things come to mind if you've gone let's say through this adoption path and you've kind of implemented attack prevention on your high risk APIs and you've got some audit trail coming in the two things that we've heard from customers if you've already gone through these steps number one try to establish end-to-end visibility so getting that attack prevention in production environments is awesome but what you should also be trying to do is get rid of all vulnerabilities in your APIs over time one of the ways you do that is you kind of Trace back end to end to the code where the API is defined and you work with the application teams and the owners there second thing is correlation one of the things that a lot of organizations struggle with is kind of a disconnected set of data around all of their cybersecurity signals and so one of the things we've heard from a lot of organizations is hey my APIs are actually just a piece of my overall Cloud environment what I'd like to do is correlate my APIs to my overall Cloud stack and look at that as part of my cloud application environment in order to either assess risk or to assign who's responsible for responding so end to end correlate with other stuff in your in your environment if you're already that far ahead of the game.

‍

Alan

‍

Excellent excellent I have a couple of questions here that are along the same team so maybe you can handle them all together um where did you get all of the data from how current is the data and what has happened since the report came out? 

‍

Jeremy

‍

Yeah great question so we got all the data from a lot of research so we we monitor a number of cyber security sites we are also directly in touch with a few uh people who do research in the API security area and they report some of that data back um by the way we actually uh track all of it on the footer of our website you'll see a link to something called the API data breach tracker so we have all of the data that we are able to share is posted there uh you can see the source material for where we got all of these breach events there um you're welcome to have at that yourself or or peruse that on your own but primarily we got it through you know kind of Open Source across the web second we released this report initially I want to say in kind of April of this year so a couple months back so that's about how current it is there definitely have been breach events since then, a couple again on the automotive side around connected cars a pretty major one around power usage meters recently uh one just a couple of weeks ago that did that uh just leaked 50 million user records on a media site in Asia um so you know the breaches continue to happen there have been some pretty large scale big ones from again big name companies where you know you can't really say like it's just small companies having these problems.

‍

Alan

‍

Right, that was very good thanks Jeremy uh I have one here and that we were bound to

get, so what impact do you think AI will have on APIs?

‍

Jeremy

‍

Yeah this is certainly one that I get a lot when talking to anybody nowadays because of course AI is the hot thing in the tech landscape I mean look there's both good and bad and AI specifically from the API security standpoint we'll get into other areas around AI but just specifically thinking about API security the good is APIs like a lot of things create a lot of data they create log files they create transactions they create records of what is being requested who's doing it, etc. there are things that we can do with AI tools to kind of analyze API Behavior

usage behavior patterns, etc. we can look for anomalies we can look for specific patterns in the research and we can do that at a scale and at a speed that is actually beyond human capacity so there's some really good obvious scenarios where we can benefit from AI. 

‍

The bad side is of course that hackers have ai too and so when we think about some of these particularly some of these secondary breach vectors around things like excessive data exposure or injection, AI can be used to kind of test APIs or to kind of product APIs repeatedly like oh I could extract This Record well let me create every version of that record ID that I could think of using some AI tool and try to request those records as well so I do think as we go forward we will see some APIs breached with the help of AI unfortunately I mean it's just you know our job to to stay on top of that as best we can and to you know use it for for the good side of things to improve our product and services as best we can.

‍

Alan

Great, thanks. Amelia has another question in here: what are all the actions and events that should be logged by the application?

‍

Jeremy

‍

Yeah that's a great question, we have an opinionated view on this though again you know from our own observations knowing that things happen at the application layer we really make sure that we want to try to capture as much as possible so we do things like capture um you know Source IP address user agent timestamp we do an IP lookup or organization and geography and we try to kind of establish personas based on that from the caller standpoint. 

‍

But of course we know IP addresses are both fungible and ephemeral and so you know you can't rely on IP addresses on their own you should track them to be sure so all of that from the caller standpoint we should also track let's say like the performance time the response time of our APIs as well as the data going out you know you may or may not need to scrub the PII from the requests and the responses depending on your own let's say gdpr or HIPAA or whatever Regulatory Compliance requirements you might have we do that for you know for our own

service and for our customer we do scrub PII out but we do particularly find that one of the most important things is to log the data that has been returned why because for that you know knock on wood hopefully it doesn't happen but for that time when you do get breached.

‍

You know we just saw a I think a new regulation come into effect or at least get proposed uh just yesterday or the day before that all firms will need to disclose their cyber security breaches within four days and along with disclosing the breach you need to be able to understand the impact of the breach you know who was affected was it just Jeremy and Alan or was it everybody in our data set and we're going to have to respond based on that so we really think you know you need to log pretty much everything you see on this page and maybe even a little bit more we do we track everything here plus a bit.

‍

Alan

‍

Gotcha gotcha so look we're we're just at the bell I'm going to squeeze one more question in so quick question for Jeremy: do you recommend deploying a multi-API security vendor approach similar to traditional WAFs, this would assume that not every API is the same.

‍

Jeremy

‍

Great question um there's a lot that goes into it so it's not a quick answer but look I really recommend for every organization to kind of take the approach that makes the most sense for your organization if you think about kind of that adoption maturity path the first two steps here are really around to kind of identifying and assessing the risk to your organization so it's about finding your APIs, understanding what kind of APIs they are, how well built they are what data they're processing etc., based on that you might want to take a multi kind of a multi-type or a multi-modal approach to API security because you realize that you've got these rest apis over here in these graphql apis over there or you've got these public APIs here and those private APIs there that is a decision that you probably need to make but what I would say is like the most important thing is to make an informed decision based on the risk and really based on the tolerance everything we do in cyber security is really informed by the risk to the organization and the risk of breach or reputational damage or whatever the risk that is important to you and your company is so I always say start with discovery and inventory go to assessment next and then based on the risk you discover from that assessment then make an informed view on how you really want to try and tackle the problem.

‍

Alan

‍

Excellent great thanks, Jeremy.

‍

So look I think we'll wrap things up there if you could just push the slides on um to the final I'll show people where they can access um so on the left here guys you can get the full state of API security report that Jeremy has just shared insights from and also to let you know this is a series of webinars we'll be doing one a month we're going to aim for the final Thursday of each month and so if you'd like to register in advance for our next one whereby we will look at the most recent update to the Owasp API security top 10, we'd really love you to join us and so just from me from Jeremy from the whole team here at FireTail I just want to thank you all for joining us today and we will be sharing the recording of this so I know there was a couple of attendees that might have come in late you'll be able to access the full presentation once we publish it on our website so thanks again and look forward to seeing you on future webinars take care.