Jeremy Snyder and Paul Mansour-Geoffrion unpack the updated Owasp Top 10 list of API security threats, and go into detail about each one and what you can do to prevent them.
In the past ten years, API use has risen to never before seen heights and with it, so have API attacks and breaches. In fact, over 83% of all web activity is now API-related and APIs are rapidly becoming the number one digital attack surface.
Listen in to learn the biggest current challenges and how you can overcome them with knowledge from the OWASP Top 10 list and more to secure your APIs.
Key topics covered include…
Jeremy
So first of all I'd just like to say thanks to everybody for joining us on today's webinar we're really excited to talk to you about the Owasp API top 10 updated version for 2023 we're going to be going through some of the you know kind of compare and contrast exercise looking at what's changed from 2019 today talking about some of those differences some of the things that stayed the same talking about some analysis around some of the issues identified as well as discussing some technical details and discussing some implications for strategy around API security so before we kind of kick off just wanted to give everybody a quick overview on how today's session will go we'll try to keep the webinar to kind of the 35 to 40 minute range we will do our best from our side as the presenters to keep the content under 35-ish minutes to
try to leave a good five minutes of Q & A time at the end, please do drop any questions as you go into the chat window if it makes sense. I'll try to work them into the course of the presentation if that's not possible we'll certainly have time for Q & A at the end.
So as I mentioned you know the big focus of today's presentation is going to be on that Owasp API top 10 2023 edition if you haven't had a chance to review it, well you're in luck because today we will be talking about that and helping you understand what's changed we'll also talk about why this has changed why some of the priorities might have shifted and why some items have sort of stayed the same but also sort of changed and again what does this mean for you with regards to your own organization's API strategy.
As I mentioned, we’ll have time for Q & A, we have also prepared a report around this that we will be sharing in the presentation and we'll also be sharing a link for everybody who's joining us today couple things in the way of housekeeping, as I mentioned there is a chat window you should all be able to drop any questions that you have into that window please I would encourage you to do so I do see all of that similarly if you start to see that you have any technical challenges you know you can try and we will do our best to sort you out on that side.
Also just from a standpoint of logistics today's session is being recorded um and the recording and the report will be available after the webinar uh we will be sending that out to everybody who RSVP’'d automatically in a just after the event if you lose connection for any reason or you do have to leave the webinar early for whatever reason, fear not you will have access to that recording after the fact and similarly if you want to share it with a friend a co-worker a an acquaintance you'll be able to do that as well.
So just by way of introductions my name is Jeremy Snyder I'm the founder and CEO of firetail I'll be hosting today's session but the bulk of the presentation today will be done by my co-worker Paul Mansour-Geoffrion who is our director of customer success. Paul do you want to say hi and you know share a few words about yourself?
Paul
Sure yeah, as you mentioned I'm the director of customer success here at FireTail been with the company for around the year at this point, before that I was working in since roughly 2017 Cloud security posture management so hopefully I can share some some of my learnings over the past year of research in API security and then tie it back to my experience previously as well.
Jeremy
Awesome awesome great well thanks for taking the time and certainly thank you so much for all the work that you've done in preparation for today's webinar and preparing that report that I mentioned and also doing the analysis work around the changes in this space.
I've talked a lot about changes kind of in the introduction here but I think actually before we dive into the changes um it's it's kind of notable that in four years since the last revision of the Owasp API top 10 here we are in 2023 and even four years later the top two items have remained the same so first can you kind of help us understand these vulnerabilities why you think they're so prevalent and why nothing has changed on this front in that four-year time period.
Paul
Sure uh okay let me break down your question here so first what are these these vulnerabilities and why why haven't they they changed? So well there has been a slight change you can see at least for the second item we've gone from broken user authentication to Broken authentication I think that's just from a vocabulary standpoint making it so that we're tackling authentication not just for user objects but also for- apologies about the the noises in the background- but um yeah covering authentication for more than just uh user objects and then for broken object level authorization that's just the authorization that's at every level um we'll get into actually the specific differences between those two vulnerabilities I know they're um they're oftentimes confused by by developers which does end up leading to um to some breaches
Jeremy
Yeah yeah I mean speaking of breaches I think you know one of the interesting things is that we've done some analysis work around breaches um and it does seem like these two items come up again and again and you know I guess one of the things to kind of highlight here that I'd like to to try to understand for the audience is you know when we talk about something like broken object level authorization or Bola as it's often called you know just understanding what that means and how that actually works I think um could be very useful for the audience I know you've got an example here that we've prepared because you kind of go through that for the audience and help them understand you know what does Bola actually mean?
Paul
Sure so in the example that we see here we can see that the the attacker on the left hand side is authenticating himself to the user 1041 and so that's fine right that's expected the the attacker probably went through a normal path for sign up and then was able to get uh authenticated by the the platform what's not okay here is that um well for one since the user identifiers that we're using here sequential you can see it's going from 1040 to 1041 1042 those are extremely predictable right it's very easy for the attacker to then easily query those other user objects now where we get into authorization here broken broken object level authorization is when this attacker despite only being authenticated to user 1041 is also able to request and receive the user objects of other users despite having no authorization for it.
Jeremy
Okay and so it sounds like what's missing in that case is okay we know that user you are user ID or the attacker is user ID 1041 what's missing is then this check that says is user ID 1041 allowed to access data record 1042 and 1043 if I understand you correctly.
Paul
That's that's absolutely right Jeremy and I do want to point out just because we glanced over the previous slide that's the research that we've done right over the past 10 years of of breaches to APIs um essentially we've noticed that authorization and authentication have been the primary cost for the vast majority of um of data breaches for for Enterprises and and governments um API related data breaches and and yeah attacks uh so right if you're covering at least these two you're doing the vast majority of the the work to secure your your APIs and that's why again they haven't changed or there has only been a very slight change in the wording between the 2019 version of Owasp and the version that's been released this year.
Jeremy
Yeah that that makes total sense and I kind of went back to the slide as you were talking there for the benefit of our audience so anybody who wants to kind of see the breakdown across those categories and maybe capture this or anything like that I did want to point out as well that um the analysis work around this is also available in our API security report that is uh on our website as well so if you want the full details um please do feel free to check that out as well so we talked about Bola um let's talk for a second about you know this kind of question of authentication and authorization because I do know that this kind of um comes up
very often and um I think there's a lot of confusion around you know what is authentication
what is authorization why are they not the same thing I I know if we could zoom out for a second objectively we all know that they're not the same thing um but you know maybe just kind of like for full explicit clarity explain here you know just remind the audience what is authentication what is authorization.
Paul
Yeah authentication is basically I am who I say I am authorization is am I allowed to do what I say and allowed to do uh this despite it's a separate concept to authentication and I I do want to emphasize that oftentimes uh Security Professionals are gonna abbreviate these two words to just off which can lead to some confusion much better to use off n for authentication and auth Z for authorization just to make that clear distinction.
Jeremy
Yeah I think that's a great uh a great piece of advice to just kind of keep in your mind as you're having those conversations around identity management relative to APIs auth is a kind of confusing uh shortening so just try to make sure to be very explicitly clear and if we kind of think for a second about that previous example that we gave authentication would be establishing that that was user 1041 authorization would be the check afterwards to see whether 1041 is allowed to access 1042 and 1043 these data.
Paul
That's right.
Jeremy
So I wanted to take a second to kind of talk about what I think is maybe a point of some
confusion for a lot of people who think about securing APIs because we've got this thing called a web application firewall and it's existed for a very long time and I know a lot of organizations use them but I know you've done some analysis work around web application firewalls and whether they do or don't work for API related issues I'm specifically related to authentication and authorization I want to pull up a chart here that I know you've put together talk us through what we're looking at here and you know why it does kind of lead us down the direction of what you've titled here you know existing approaches just don't cut it help us understand what is it that's missing or what is it that we need to look at from the standpoint of authentication and authorization that we don't see with a WAF.
Paul
Sure I think to answer that question I'm going to need to at least mention a little bit of the history behind the API security I think if we come back 10 years APIs wasn't as much of a used word or at least it wasn't as much of a concept that was used to define products and types of infrastructure um people back then were more talking about the network layer and that's when a web application firewalls were enough right to to monitor that that Network layer of data passing through to your infrastructure nowadays we need a lot more context if
we're going to be at least aware of what's going on with our work with our APIs so if you're exclusively using a WAF to protect your APIs you're not going to get visibility into the arguments and the request parameters that are being used by the requesters the the people actually trying to use your API and then in response you're not also going to get the the request payloads that they're putting in and the the response below so you just don't have any idea of what your application is doing with the traffic that's hitting…
Jeremy
Yeah, I- go ahead.
Paul
Yeah I was just going to mention the right hand column whereas if you're looking at API logs from the application layer the minds API stands for application programming interface if you go to the application layer that's where you're going to get the best visibility.
Jeremy
Right right so that's kind of deeply integrated into the application logic pulling out those elements that you mentioned the arguments and the request parameters and potentially the request and the response payloads that help to kind of map out what actually happened in that API transaction to understand the flow of authentication and authorization and whether it should or should not have been approved so that's super helpful um you know I want to kind of get back to our train of talk around some of the updates and I'm kind of want to start with one of these new items that has this you know just roll off the tongue acronym um I'm sure everybody's gonna love talking about bopla for the next couple of years so can you break this down and help us understand what this is?
Paul
Sure, so it stands for broken object property level authorization and it's essentially a combination of two items from the 2019 list so if you're if you look at mass assignments and you look at excessive data exposure those two items were essentially two faces of the same coin so it's it's either you're breaking into object properties to exfiltrate what should be confidential or you're modifying an object's properties to gain some sort of Advantage with that that system. So if you combine both of them you get broken object property level authorization. So, for example-
Jeremy
Could you give us an example-
Paul
Yeah, I read your mind there uh the the idea is essentially if a marketing team is trying to put up let's say a rotating user feed on the the public website and that's rotating user feed essentially displays the user's first name and the city that they're from that's innocent enough right there's there's no personally identified identifiable information there that warrants a notification of a breach the problem is when the developer that's charged with implementing this feature returns from the user database the whole user object and so the public website so then it becomes very easy for any sort of client any sort of attacker any sort of user to then see those full user objects you don't need any hacker tools to do this just your your standard web browser will be enough to to get that stuff worse would be if those users are then able to call that that endpoint the the user's endpoint the user's database and actually make modifications to the user objects that would be yeah a whole broken object property level authorization sh*t show- excuse the the phrasing…
Jeremy
No worries no worries I think we can all talk openly about the challenges of some of these security issues uh all good I'm sure the audience won't mind the fruity language a little bit here and there um I want us to move forward a little bit and you know just very quickly could you talk on a couple of mitigation strategies around this BOPLA issue.
Paul
Yeah, I definitely you should plan your inputs and your outputs when it comes to your APIs where you're fetching data from the back end and presenting it's in the front ends you should handle data sanitization uh from the server side so that there's no possibility of any extra excessive data being returned to the front ends and you should also definitely maintain an API contract and ideally make sure that it's also being enforced though that can get a little bit complicated for organizations.
Jeremy
I understand that got it got it that's great I think that's super helpful for the audience so just remember those couple strategies so moving on we've got a little change in the fourth item on the list we've moved from kind of lack of resources and rate limiting to unrestricted resource consumption talk to us a little bit about this theme in general and why the slight changes you see it.
Paul
Yeah it's it's as you said it's a very slight change in the sense that it's essentially a rewarding we're going from looking at the cause of the problem to the uh you know the the the vulnerability itself is uh you're allowing for unrestricted resource consumption so essentially this vulnerability is that your server is getting so much traffic so much fake traffic that it's unable to serve real users real customers and so oftentimes we're speaking about a distributed denial of service attacks here so one way to mitigate this would be to implement resource and rate limiting and pagination for your APIs make sure that you're not returning everything every single thing that's being asked for limits into bite-sized chunks what can be sent back and then also as much as possible Monitor and block suspicious traffic malform requests that's um are just using up your compute time without actually attempting to do a legitimate transaction.
Jeremy
Yeah I think that's such an important point because around this I know you know historically we thought about DDOS as basically just flooding something with traffic period but on the side of the API that last point that you raised which is kind of certain parts of the transaction flow that take up a lot ofcompute time that can be an effective DDOS attack strategy as well as just say oh okay your authentication endpoint is super slow well I'm just going to flood specifically that with a bunch of authentication requests that look like normal API traffic and we have seen attacks that look like that out in the out in the real world so that's a great great point to highlight so moving on to the next item it looks like we've got kind of a uh this new one called uh sorry we've got this one restricted unrestricted access to sensitive business flows what is this all about?
Paul
Sure so it's a new one for this year I don't think there was an equivalent one for uh 2019 that we can really make a a legitimate sort of comparison point to essentially here and I think it goes to show how uh how how much APIs have risen in importance over the past four years essentially because now it's it's very normal for uh wide sets of users to interact with a software in a programmatic way using APIs to do very normal transactions the example that I like to use here for a breach that was uh caused by this unrestricted access to sensitive business flows is something that happened actually a few months ago when there were some Taylor Swift tickets being sold on one of the most popular platforms for uh for ticketing essentially what happened is that within the first 15 minutes or first 10 minutes or so of those uh those tickets being put online they were all bought up automatically by Bots uh essentially the sensitive business flow here of being able to purchase tickets was unrestricted that perhaps could have been mitigated with some uh some some capture checks or some some other user flow analysis to make be able to make a difference of who's a real user and who's a fake user what ended up happening yeah is that this this ticket vendor was dragged in front of the US Congress to have to explain themselves to all the congress's uh Congress people as to why their their children weren't able to buy tickets for the uh for the concerts so yeah something to to keep in mind um for your own apps.
Jeremy
Yeah absolutely absolutely and and you can see uh due to the audience you can see that's kind of the third bullet point example we've got there we've got a couple other examples um that are kind of taken from real world scenarios that have been observed or um discovered by security researchers who have been looking at flaws around APIs um so hopefully that gives you some uh some perspective on why this is so impactful and why it's an important new addition to the list so moving on we've got another new item on the list um or we've got kind of like two new items here we see you know a little bit of a change with security misconfiguration dropping down a spot and we've got this new entry server-side uh request forgery ssrf which I think is an acronym many of us will have seen what's happening here?
Paul
Sure so let's yeah let's first talk about server-side request forgery this is essentially where uh an attacker would would use a vulnerability this this type of request forgery to move laterally from a public-facing server to internal only resources so this can obviously lead to data exfiltration if the the servers then forced to interact with resources that it wasn't meant to interact with or it wasn't um initially intended to interact with so the example here is if for example your your web app allows for users to provide a URL to provide their their profile pictures instead of providing a very normal URL with a PNG or a JPEG there an attacker could provide a link to an internal resource in your own system so if your API hasn't been designed hardened against this type of attack so to make sure that it can only interact with white listed or allow listed addresses of resources then it's quite possible that it's just going to feedback the information that's been requested the whole for example the whole user stable or something like that um so yeah definitely something to watch out for.
Jeremy
Awesome and and kind of the second part of that so that's the ssrf side of it can you give us some example of security misconfigurations I it looks like you've got a few outline but to me when I see the title securing this configuration that's such a broad category that I almost don't even know where to start thinking about it.
Paul
That's so true Jeremy and I think that's might be actually one of the reasons why it's dropped off in in priority from at least one rank because it is such a big category that has a a lot of different ways to be interpreted so just to name a few uh you can use secure transport protocols you can uh have if if you have proper HTTP methods in in place not excess ones that you don't actually need if you're using security headers and you follow the well-architected framework or other comprehensive infrastructure governance Around The Works you're going to be a lot better place with regards to Security in this configurations the idea here is try to follow as many best practices the latest best practices as you can with regards to to the setup of your APIs.
Jeremy
gotcha that makes total sense so moving on um the next one we've got is looks like a little bit of a title change but I'm not sure that the gist of this next item number nine here is really all that different looks like we've gone from improper assets management to improper Inventory management um talk to us a little bit about your understanding about what's what is this concept and what the slight change might be.
Paul
Yeah um I think part of this is the influence that the evolution of cloud security has had over the whole I.T security industry so it's a very common Concept in Cloud security to have an inventory to at least know what you have in terms of resources powering your your infrastructure I think that's exact same concept is being brought over to APIs so we're we're moving from improper assets management to a more holistic inventory management that includes more than just the the API uh let's say assets it may include especially given that the next one insufficient logging and monitoring has been removed from this year's list I think it it now belongs to this improper Inventory management category where our inventory should also include logging capabilities centralized logging comment taking in the traffic from as many places as you can
Jeremy
Yeah yeah and that makes total sense I know you know just as you said you and I both have a background in some experience in Cloud security and I know one of the challenges that I've seen a lot of organizations face relative to their APIs is that when you think about Cloud platforms APIs can kind of live anywhere they can live on Virtual machines they can live inside containers they can live on serverless functions they might or might not have any number of network infrastructure components in front of them like load balancers API gateways waffs or or some combination thereof and I know a challenge I've heard from a lot of organizations is that all of those things log to different locations by default and so you have this challenge of kind of getting all your logs together in one place in order to do good analysis of what's happened with your APIs what kind of traffic there's been what kind of potential malicious behavior there have been so I totally see the importance of API login I think you're probably right it's kind of implied under in management with this new item just a quick call out to our audience here-
Paul
We're coming yeah oh sorry go ahead Paul yeah I was just going to mention at this point for improper Process Management we we've just talked about the runtime production side of things the production uh assets management side of things but this should also include uh having a proper release management if you don't have any zombie APIs coming back to haunt you in the you know in the future as you've released patches for your your latest APIs um you should also be running distinct pre-production production you know from a Sandbox development test staging in prod environments for your API so you can properly test it out and make sure you have no production data in any pre-production environment so all of this type of stuff I think is included in this in this category.
Jeremy
Yeah makes sense I mean a lot of it is kind of security/ I.T hygiene related topics as well that are kind of General best practices and I think can often get forgotten in the rush to release the latest and greatest and the newest cool thing that is going to move the business forward relative to that API and on that one point that you raise there around releases I know there's been issues out in the wild where organizations have had previous versions of APIs you mentioned you know people tend to patch only the newest version of the API going forward but they might still have partners that are consuming old versions of the APIs that are still left online and those uh those older releases might still have vulnerabilities in them so I would say that that also kind of falls into this category of asset management would you agree?
Paul
A hundred percent.
Jeremy
Awesome awesome just a quick note to our audience we're coming up towards the end of the top 10 list and some of the analysis there uh and I did want to kind of put the call out for any additional questions please feel free to get those in in the next few minutes we'll be moving into q a here pretty shortly so moving forward on the um on our list of items we've got this last one unsafe consumption of APIs it seems like this is a brand new entry to the list and and this is kind of a um you know kind of maybe replaces some of the some of that kind of General category stuff so talk to us a little bit about this and what we're looking at here.
Paul
So this is less about the maintaining and offering of an API as your own system and more about the consumption of APIs as it's said in the title of this uh this vulnerability so I think this goes to show how how much there's been a growing interdependence of I.T systemsover the past four years and how much the Upstream APIs for example if you're using twilio or other types of developer friendly APIs or APIs used by developers to power their own systems if a vulnerability affects those you don't want to be impacted by that you have to put into place some measures to mitigate this sort of these sorts of issues so to say it in a sentence the zero trust model applies to third-party Integrations too don't rely on the external APIs and and ensure yeah that's that you're sanitizing at least the inputs that you're getting from from those systems- sorry Jeremy go ahead.
Jeremy
No I was just going to say it's kind of like a trust but verify approach to working with third-party APIs and I think like the zero trust model is another good way of thinking about it you know it's only okay if it's been kind of um if it has been kind of verified through whatever security process is right for your organization but I think it's really important to highlight that you know APIs people use various analogies talking about APIs I've heard the the plumbing of the modern internet the connective tissue of modern applications whatever analogy you want to use it's it's obviously a thing that connects to systems and those might be one part internal one part external and I don't see that trend changing anytime soon if anything all of the data shows that the consumption of third-party APIs is just going to go up and up and up and so having a view as to what third-party APIs you are using and what the you know potential impact is there is I know something that a lot of organizations um should be watching out for to keep a safe ion um you know apis are of ultimately kind of an ecosystem type of tool so I know that was number 10 on our list I want to kind of get your general thoughts around the future of API security it's been super helpful to go over this list we've seen the evolution we see some of these changes what do you think is going to happen in the next couple of years regarding APIs and maybe like how organizations think about securing them and how bad actors think about abusing them?
Paul
Yeah that's a that's a great question Jeremy um I think we have to start by stating that API security as a concept as its own concept is a relatively new it maybe in the past two years that people have started talking about this as its own thing versus like application security or Cloud security that had been around for a much much longer time minimum like 15 years for for both of them right maybe Cloud security a little bit less than that but you get the idea. So I think we have to look at historical comparables to be able to see where API security is going at the very minimum I think there's going to be a lot more standards covering the API security it's no longer just going to be Owasp that has this top 10 list of um of vulnerabilities there's going to be a lot more coming out whether it's from CIS nist any other framework ISO that's um that are regularly published stuff for other layers of the infrastructure they're going to start doing the same for for API security so in a word it's going to be formalized.
Jeremy
Okay and what do you think about on the attacker side any thoughts there?
Paul
Well we've seen the trends we've we've done the research Jeremy the the breaches are getting bigger more severe affecting more parts of the infrastructure yeah so on the attacker side I don't see this problem going away without some serious effort on the part of the the whole industry to make everybody more mature about this.
Jeremy
Yeah and I think one of the things that has me a little bit concerned is you know I have to get asked by people hey what's the impact of generative AI on APIs and API Security in particular and one of the things that I am keeping an eye on for sure is what can what can generative AI do in terms of uh in terms of creating and launching attacks against apis can you give a generative AI tool a set of prompts that would cause it to come up with a set of requests that may look normal but again look to abuse the business logic of an API maybe look for Flaws in some of the things that we talked about authentication and authorization maybe look for uh you know creating um unsafe consumption patterns that do cause ddoses so you know that's something that I'm certainly keeping an eye on from my perspective as well but I I certainly appreciate your Vantage Point and I think uh thanks for sharing that with the audience we do have a couple of questions trickling in I do want to take those so let's get over to those first question that we we have here what are the specific things that we should look at to make sure we're aligned with the owasp API top 10. So maybe some concrete recommendations from your perspective.
Paul
Sure, fortunately we've recently published a sort of a list of at least some issues roughly 25 or so that's um you can follow they're highly actionable things like making sure that you're you're including the no additional properties option in your your spec files making sure that there's no possibility of a bopla attack using that at least if you're enforcing it I'm actually going to share I think I can share in the the chat or if you could could show the our findings page on our websites I think this is a very good place to start if you're looking for um a list of actionable recommendations that are tied to the Owasp list this is um likely a very good place to start.
Jeremy
Yep I've just dropped that link into the chat window in response to this question so hopefully that is available to everybody feel free to have a browse around there we are constantly kind of refreshing and improving that content with new discoveries that we have and with additional contextual information um it actually kind of leads well into one of the next questions that we've got here from the audience which is how can security teams bring developers and app owners along when it comes to API security could not have been a nicer segue for you Paul so maybe talk about that a little bit.
Paul
Yeah that's a that's a fantastic question um I think it it hints at the cultural problem that we often see when it comes to starting a new security initiative in any sort of business not necessarily even in I.T business but it if I take a few examples from my my past life as a cloud security practitioner you often have to have a cross team organization of such one organization I was working with called it the um the Guardians of the cloud where it was cross-functional um basically a best practice working group that would meet every x amount of time to discuss what does best practice look like with regards to the cloud for our organization if you if you at least start by defining what your standard is then it becomes much easier to know what to actually enforce if you don't know what is best practice you know it's not a good place to start from.
Jeremy
Great, I'm just typing out a little bit of a summary of what you said there uh great I've got a follow-up and I'll finish typing that in I got another question coming in here do you think that protecting APIs with open API Swagger files and using them as a policy in the Waf is a good approach?
Paul
A policy in the WAF so that's um that's a new one for me um what is what we do recommend and this is very much a fire tell recommendation it's not just coming from me I think it's as a company we would wholeheartedly agree that your spec file should be your source of Truth with regards to how your API should behave um and there are methods out there open source methods out there not necessarily just from us but we do have a method that you can use to ensure that your spec file not only is the intended source of truth for how your your your API should behave but is the way that your API behaves essentially there's an enforcement mechanism there and um you know you could take a look at the firetail libraries for this there's there's others out there as well that you can you can do a quick Google search for it but yeah we'll if you want to use those we'll be happy to help you out with them.
Jeremy
Awesome awesome and I've got a question um while I post that response I've got a question from my own side you know you did this analysis work around kind of the 2019 version to the 2023 version uh compare and contrast exercise that we just got got done kind of going through line item by line item I'm curious from your perspective as somebody who's been in cyber security for a while who's has both a cyber security and a development background so you've got the perspective of somebody writing code in the perspective of somebody looking at securing environments what do you think like kind of at a a more of a feeling level do you feel like this new 2023 version is better worse or just different if you had to kind of give an answer to that?
Paul
Yeah it is what it is um it's a it's a first step it's a great first step to be honest because it does formalize in a way what should be done to protect APIs but it there aren't that many actual actionable insights there the ways that you can recommendations that you can directly take from that top-down list and then apply in a consistent way across your entire infrastructure um this I think is still yet to come.
Jeremy
So you know if I hear you right it kind of sounds like what you're saying is like hey great this is a you know one additional step down the path of identifying the risks but it's not necessarily let's say a set of controls or a set of security best practices or recommendations for how organizations should think about better designing or better protecting their APIs.
Paul
Yeah, these are guiding principles.
Jeremy
right right so I would almost consider them to be more of let's say a good starting point for a threat modeling exercise for thinking about like Hey we're putting out a bunch of apis into the world what should we be worried about you know these are or almost like a checklist of of risks and concerns that we need to think of got another question coming in from the audience what's the best place to start when it comes to identifying all of the apis in your organization?
Paul
Sure um great question identifying all the apis in your organization well I think for starters you probably need to have a chat with the people developing those apis to see where they're actually running them because that's that's the thing with APIs right you can literally run them from anywhere you can have computes right whether it's a it's your own laptop that you're running a server from or it's a cloud environment or what have you so have a chat with them and then see how you can get access into those environments so then ideally you plug in an automated solution like FireTail or you know there are others to essentially make your inventory and then from there you can very easily see which ones have more traffic which ones maybe have some vulnerabilities associated with them which ones deserves to be spun down to limits uh the the attack surface.
Jeremy
Got it and I'm just typing up a quick summary to that for uh people who have posted the question just a quick check on time we've literally got about two minutes left in our webinar today um so if you do have any last questions now is the time to get them in otherwise we will move towards kind of wrapping up in just a second here and uh looks like I'm just giving a quick view onto things okay looks like we've actually handled all of the questions that have come in over the chat so with that and coming up on time I did want to point out to everybody who's joined us today again just a reminder you will be getting an email in the next couple of days with a link to the recording and a link to the report as well if you are joining us live right now I did also want to mention to you that I believe you should be able to go into the uh into the chat window or into the description of today's webinar and access the link uh directly so the link should be in the description of today's webinar to get this report on the changes to the top 10 API security risks for 2023. uh with that just one quick final check to make sure we don't have any loose threads on Q & A from the audience I just wanted to thank you Paul so much for the time and effort that you've put into preparing this analysis preparing the report for our audience and taking the time to share your thoughts with us today um just again as a reminder thank you for taking the time to join us you'll get any email the recording will be available if you do have any questions please feel free to reach out to myself or Paul or the entire firetail team you can just find us at www.firetail.io online we've got this report available we've got our previous work around the API security breach evaluation over the last uh 10 years and we've got an upcoming webinar uh next month we haven't yet announced the topic for that webinar but do stay tuned for an email update that will tell you what is going to be going on we hope to see you on that or a future webinar and again for myself Jeremy for Paul for the entire FireTail team thank you so much for taking the time to join us today.
Bye-bye!
