Transcript
We're about two minutes past the hour, and I think we've got the majority of people who are planning on joining us who have now joined. So we're gonna go ahead and get started with the webinar. I'm Tim Erland, I'm the VP of product at Wallarm, and I'm thrilled that you're all here to spend a little bit of time with us. I'm joined today by Tejpal Garwal, who is the founder and CISO at CyberAdvisor and has a bit of a history and career around application security and API security. So welcome Tejpal, thanks for joining us. Thank you, Tim, thanks for inviting me. Hello, everybody. A couple of housekeeping items before we get started. We are broadcasting this webinar both on Zoom and live on LinkedIn. So you could be on either of those platforms. If you have questions during the webinar, if you're on Zoom, you can put them into the Q&A. If you are on LinkedIn, feel free to add a comment with your question. We'll do our best to get to those questions during the webinar or at the end, depending on how the timing goes. This session is also being recorded, so you can always find it on LinkedIn as well. So if you wanna watch it again, it'll be on LinkedIn, but if you also want access to the recording, just let us know, and we're happy to share that recording as well. So with that, we will get started on the idea and topic of debunking some API security myths. I thought it would be a good place to start with, to talk a little bit about why API security is kind of a misunderstood topic. This sort of dives into the challenges around API security, or maybe even a little of the history here. And I thought we could start just talking about the API landscape and what it looks like in 2025. So, Tejpal, what are you seeing in terms of the API landscape and how it's changed in the last, let's say five years, maybe? Yeah, so the API, I think, becoming a very kind of a core fabric between the applications, like you have the service-oriented architecture, or you have different applications talking to each other. So like traffic is going back and forth, and API is the layer. So I think it's growing more and more. So it's kind of becoming like a, sort of that connective tissue. I've, like, you know how we used to say that, you know, sort of the network is the connection. It's now more like the APIs are providing that connection. Exactly, exactly. That's exactly what's happening. It's growing, and more and more dependency are coming to API in these scenarios, when applications are talking to each other. Yeah, and we've got, I mean, we've got this image of an iceberg up here, which I think is probably apt, because, I mean, we certainly are aware of the APIs that are exposed externally, right? Those are the services that you might actually use via an API. But there's more than that, right? We're seeing, you know, even a bigger growth, maybe, in APIs that are internally accessible. And that has something to do with, sort of, the overall shift in application architecture. I think that's what you were describing a little bit, as APIs being used. Yeah, tell me more about that. So, when you have the application talking to each other, and it's, when APIs keep growing, you've got to know that, how many applications, or APIs, endpoints I have, and who should be accessing those endpoints, and who should be those endpoints talking to each other, public, private, and you're consuming, and you're publishing at the same time. So, as you can see, so many things are going on, and that's where it becomes very important that you not only have the inventory in general, I'm trying to say, but also what you are allowing to do, what you should not do, do. So, you should have a good documentation, in a way, where you will maintain all these APIs in your environment. And we're talking about APIs as if they're one thing, and actually, this image of the iceberg here, it's a little bit misleading, because it shows sort of AI APIs, and partner APIs, and public APIs, as if there's one thing called an API. But I want to contrast that with this technology stack, because an API isn't an API. Like, there are lots of different pieces of technology, and protocols that are behind that. And that complexity, I mean, if we were to try and layer that onto the iceberg, it would be an incredibly confusing image to show, right? That's correct, exactly, exactly. Yeah. And do, you know, we might say that the technology, API technology is evolving, but do organizations, are they getting rid of older technologies as fast as they're adopting new ones? It depends on the business scenario. However, I think the shift is definitely happening. In my experience, I'm seeing is, there are still legacy applications, those are out there, and transition is sometimes slow, or it depends on how those are operating, and what the business impacted. So, but in general, the shift is happening, and shift is happening in a noticeable pace, I would say. Yeah, yeah. I think, you know, it would be interesting, we can do a little experiment and see how it works. For the folks on LinkedIn, you could put in a comment, and for the folks on Zoom, you could put this into the chat. Pick an API technology that you're using today, and one that you'd like to use in the future. And don't tell us which is which, but just comment those two technologies. So, you know, maybe you're using REST today, and you want to use GraphQL, just put REST and GraphQL. And I'm interested to see what pops up if people put those in the comments, or in the chat in Zoom as well. So, it's clear that the API landscape is growing as a whole. We're seeing more APIs being developed. We talked a little bit about the, you know, sort of the application architecture being API driven. I want to touch on how you see AI impacting the growth in APIs. Because we've got them on the iceberg image here, but, you know, I think a lot of people think AI and APIs are sort of separate things, but they're pretty closely related, aren't they? They are, they are. And especially if we talk about the AI agent, again, I think the main fabric is API. Say, suppose if I talk about white coding, or something I want to build up a website where I want to have a front end, back end, back end and the database. And I can, with the AI agent, I can have these distinct tools or technology connect with each other and make it very fast. And what's happening is the API is playing a very critical role in this, again, in this scenario. However, if I'm an AI enthusiast, I even want to show off, I can build an application within two hours and say, hey, this is the total data driven transaction application. But I have no idea how those applications or APIs are talking, whether they're secure, who is accessing the data, and the compliance and all those things are still a black hole. And developers most times do not care, depending on who is developing. Definitely corporate developers do not do that. But in general, that is the kind of scenario. Yeah, yeah. So not only, I mean, you have the, like the AI agents themselves, which are driven by APIs. And then you have the APIs that those agents may be creating in order to deliver a service. And then you have the APIs that those agents have to connect to in order to accomplish some task. It's a whole like fabric of APIs that sort of are growing out of this AI trend. Exactly, exactly, yeah. Yeah, yeah, that's very interesting. So that's the sort of the growth in the landscape. The second attribute, which is related, I mean, these are all related because they're connected. The second attribute here is this idea of API sprawl. So if we have more APIs, we then have this problem of like managed versus unmanaged APIs. And I think when we talk about API sprawl, we're talking about sort of the growth of that unmanaged side of things. And there's a prediction here from Gartner, which I've been looking for a replacement for. This particular prediction gets used all the time. It's by 2025, less than 50% of enterprise APIs will be managed. Of course, it's now 2025. So we'd love to have another prediction. Did we get to that? Are less than 50% of the enterprise APIs managed? Who knows, we're not measuring it perfectly across all the organizations. But I think there's clearly an API management challenge. And do you see the, how do you see that challenge manifesting itself for product security or application security teams? Yeah, so I think this picture is depicting a lot of messages here. And I'm liking this slide you are showing it here. So I think the enterprises from the application perspective, you can secure what you know about and you cannot secure what you do not know about, right? And then when the applications are being developed and enterprises want to push their product as fast as they can to the market, the production is kind of accelerating on the lightning speed. And I think when you say that by 2025, there will be 50% enterprise API will be managed. I think that's pretty much true. And I think that percentage might go a little down. However, there is two aspect of it, right? The management of APIs and visibility on those API. And I think this slide also mentioning about the zombies and shadow APIs. And also the public and private APIs. So I think as you said that there are the different flavors of API, how they are being used and how they are being developed and what risk they are bringing when things are happening on the lightning speed. So are, I mean, you mentioned visibility and management. It's an interesting question. Are visibility and management the same thing for APIs or are they different? They are different. Visibility is basically how many APIs, say suppose 1,500 to build my application. That's kind of where I have it. And then the management piece of it, am I keeping them up to date? Am I keeping the authentication authorization on the object label, function label? Am I keeping that thing in place and intact and making sure those aspect is up to date? That is kind of management piece of it. So I think they both go hand in hand. Yeah, yeah. But it's important to understand that they're not the same thing. Just because you know an API is there doesn't mean that it's managed. It's that visibility is just the starting place for managing those APIs. Yes, yes, yes. And you mentioned on the slide here, zombie and shadow APIs. I wanna explain what the concepts are there. There's a governance approach here or governance concept that you have as an organization, you have an idea of what should be in your environment. And then you have the actual reality of what is present in the environment. And a shadow API is one that's present in the environment, but shouldn't be there. It's not in that, whatever you have to say, this is what should be there. Usually we'd say an API specification. A zombie is one that you removed from the spec and then didn't remove from the environment. And they create risk basically, having those things are risks that get created. Okay, so let's talk about the last aspect here, which we've touched on a little bit, because as I said, these three things are all related, which is this delivery velocity. So I dug up a quote from Puppet's state of DevOps report from 2024, which said that 45% of organizations can deliver software changes to production in less than one week, and 21% can deliver changes in less than one day. So that gives us a sense of the velocity that we're talking about. When you have SaaS products, development can deliver changes at any point in time. And because more and more, as we talked about, more and more of these products are built on top of APIs, that means that you have APIs that are changing rapidly as well. What is this? I mean, we're talking about the reality of delivery velocity, but where do you see this delivery velocity or this pressure for faster delivery coming from? So I think it's coming from a few aspects, but I think it's always the market competition. I think that is one thing. And it's also, I think, the demand of the users. While this whole technology landscape is changing, AI is there and it is there for good. And everybody wants to be ahead of the game, not only in the business, but also to deliver that business value to their end users. And when that competition is there, there's a push to deliver the changes in the SaaS environment or in the product as quickly as possible to deliver the value to the users as quickly as possible. Yeah, yeah. And it is a kind of competitive pressure, which, that's pressure on the business. And the end result is it puts pressure on engineering and development to deliver faster and faster. And velocity, it becomes a key criteria. I definitely agree with you. Right. So let's touch on sort of the consequences. We talked about three things, right? Just as a reminder, we talked about the growing API landscape. So there are more APIs. We talked about API sprawl. So there are more unmanaged APIs because there are more APIs. And then we talked about the pressure for delivery velocity, faster delivery. So what do you see, given those three behaviors in organizations, what do you see as the key consequences of that API development environment, if you will? Key consequences is like, there are many. For an example, say suppose I'm delivering the application as quickly as possible, but there is a misconception I have is that if I am doing certain, let's say I have HTTPS and I would say the transmission is happening on HTTPS. HTTPS, my mindset said that, okay, my APs are safe because they are going through the HTTPS. Or I know that as a developer or product development, my all public, I have only public API and I have not exposed a private API and other sort of things. And whether I'm logging the information, whether I'm using, whether I'm doing different testing or not, but there is very high chances that you will miss a lot many, I would say the items in your checklist. So there is a perception that the way I'm developing the web application, the way I'm developing app, there's a big difference in that mentality. Because APIs are not designed just like how you develop the web application or any other applications. So there is a consideration you got to put in place and then take it from there. Make sure that those checklist, as simple as like overstocking for an example, you got to make sure that you have at least those checklist in place. And I think that is the kind of a starting point or I would say the benchmark when you have the APIs. Sure, sure, yeah. And I think you've touched on two of the consequences that we have up here. So one is that there's just more to secure, right? So with that push for delivery velocity, as you were saying, there's more complexity and more to secure. And then the shifting objectives, as you have a broader environment with more services, understanding what you need to secure, how you need to secure it changes. The only thing we didn't talk about here are really the potential for new threats as the technology shifts. And I think that's an important one. On that first slide, we talked about the different technologies and protocols. I think our little experiment of asking people to put a protocol they're using and one they'd like to use in the chat didn't quite work out. But the one that comes to mind for me is GraphQL because GraphQL is really powerful as an API protocol. If you want to exchange data, it's essentially SQL API is the way you think about it. You query data, you can batch queries together, but at the same time, it opens up a set of new threats because now you have the ability to hide attacks in a set of batched queries or in aliases or overwhelm a server by creating nested queries that are too long for the memory that that server has, that kind of thing. So there are those kinds of new threats, but we're also seeing business logic attacks that account takeover and scraping and things that leverage APIs in ways that they weren't intended as well. So I think there are definitely new threats for us to consider as well. Yeah. And I think I just want to add one more thing on the very first slide where you had the iceberg. What is visible, sometimes another perception is what I, if my API is a hidden, because it doesn't have any user interface and the perception is, it's API is there, nobody else can see it, that means it's secure. That's not the case. Yeah. That is another threat. And finding API is very easy in any app. I have a great example of that where I was talking to an industry analyst who said, he saw a client who had implemented MFA, multi-factor authentication, great, but they implemented it in their web application and they left the API supporting username and password as an authentication mechanism. And so attackers just skipped the web application, went directly to the API, used stolen credentials and they could authenticate because they didn't have to deal with the MFA by the API. And that's a good example. So there are a couple of questions in the chat that I think we can probably address here while we have them in front of us. The first one is, does MCP have a relationship, any relationship with APIs? I'm happy to answer that one. Teshpal, you can jump in if you'd like. But MCP or Model Context Protocol is an evolving standard, we should say for AI. And it's specifically designed to allow AI agents to communicate context among each other. So if I'm an agent and I have a query that I need to pass on to another agent, I can use MCP to communicate the context of that query and the intent and the limitations, that kind of thing. MCP is related to APIs because that context can be shared over and is shared over APIs, not required to be shared over an API, but generally would be shared over an API. So it drives up the use of APIs. And for API security, it requires that the tools understand the content of those MCP requests and responses, if you will. I don't know, Teshpal, if there was anything you wanted to add to that one. No, I think you covered it right. Okay, cool. There's another question here about micro and macro services and NIST Special Publication 800-228, which happens to have been the webinar we did about two, three weeks ago. So if you want a full dive into NIST 800-228, we actually did a webinar, it's available on that topic in particular, but it's a great publication. It's in the initial, they've closed the commentary now, but it's in sort of the initial public commentary phase. And it is a standard for securing APIs. It's an API security NIST publication, which is super cool. Yeah. And then the last question here was, how are companies documenting APIs and how are they structuring APIs in their BCP DR processes? Teshpal, I don't know if you had any thoughts about that. Yeah, so I'll just give my kind of, two years ago, the example, it was really, we didn't have any tool and we were literally a maintenance Excel sheet because we have very like handful of APIs. And then we definitely had made that process work and make sure that we document not only the endpoint, all the parameters and use and also the access control. But it was more like, still you have to babysit that process. And at that time, I wish that if we had certain mechanism or tool where I can have that visibility automatically, so that can be seen and maintained about those. So I think the documentation is definitely, I think that's the starting point because it gives you the visibility and depending on the amount of the APIs, but definitely have the documentation, have all the parameters, what is going in, what is going out or what are the access control this particular API endpoint should have. So that will give a good perspective and a good benchmark, I would say. So you can at least really visualize or see that where the risk could be. Yeah, yeah, yeah, good, thank you. So we talked about this, sort of the API environment, why APIs are misunderstood. And I think that the consequences there are more than just theoretical. And so I always like to follow up, sort of the statements of what potential risks there are with some actual examples. So these are real incidents that occurred in the last, this year, I think all of them are from this year. At the top, we've got this Oracle Cloud incident, which was the exploitation of a vulnerability that's been around for a while in Oracle's cloud login infrastructure. And so I think that one's, it's an API vulnerability. The reason that one's interesting is twofold. One, it shows that a vulnerability doesn't have to be new to be impactful. And two, it's a reminder that API security is more than just the APIs you're developing. It includes the products that you have or that you're using that expose APIs that could be exploited as well. And so that's an interesting example. The second example here is with Volkswagen, which was a weak JWT implementation that allowed a user to access via their API, the vehicle location and history for other users of some of their cars. And so this was kind of a misconfiguration or a poor implementation might be the way to think about it. So it's a different example. And then the last one is, in some ways, just there are lots of examples of this type. It's data being exposed via an unauthenticated API. So in other words, an API that should have been authenticated but allowed access to, in this case, sensitive data without authenticating. So some real world examples of API incidents that actually occurred. Yeah. And then also in these all scenarios, mostly the last one, NHS case, this data exposed is one thing, but the complication or the consequence on the compliance is the aspect of it. That's right. To see whose data is exposed. And I think the unauthenticated API, that's kind of a, I think, what was this keep saying again and again, saying authenticate, authorize, and then expose. But those are the very basic thing. Those are, I think, missed out in this scenario. Yeah, yeah. So let's dive into these API security myths, right? Because we have five myths that we want to talk about or debunk in this case. And we can jump right to the first one, which is, we know what we have. First myth, that we have an understanding, a good understanding maybe even, of what APIs we have in our environment. And as we talked about, Tejpal, it's not just how many, it's what risks do they pose? What are they used for? So from your perspective, why does this myth exist? Or why does it persist? What behaviors do you see that continue to sort of propagate this idea? I think the idea is the time, time to market, I would say, or the speed of delivery in the business requirement to get ahead of the curve. I think that means, I just kind of talk about it. But I think the time, whether I would want to create a fully functional API, or should I document it? Do I have that much time? So I think the priority goes to let's develop it, and let's push it to the production. And we take care of documentation later. We know it, we develop it, we know where the code exists, so I think documentation will easy part. I think that's the kind of perception. And I'm just talking with a development perspective. And that's where the things kind of missed out. That's interesting because, so I had put up here, as one of the reasons this myth persists is, you don't know what you don't know, right? The idea that, I know these five APIs exist, so I must know all the APIs that are out there, because here are the five I know about. But you're pointing out an interesting, almost organizational phenomenon, which is, I assume everybody else knows what I know. So if I'm a developer, and I built this application, it's got an API, or it's got multiple APIs, I've committed the code, it's in the repo, I assume that somewhere someone who's supposed to knows about it, and is tracking those APIs. But in reality, there's nobody doing it. And so there's this sort of, it's someone else's problem kind of viewpoint that causes this myth to persist as well. There's also this sort of developer centricity challenge, which we touched on earlier, which is that when I at least, when I talk to people about API security, 80% of the time, maybe, they're thinking about the APIs they build and develop and deploy, they're not thinking about the APIs that they bought from someone else and deployed, or that they came with a commercial product. But that's part of API security, that's part of their inventory of APIs as well, especially if any of them are exposed externally. So that idea that it's only what I build that counts, creates a myth as well. That's absolutely right, yeah. So the reality here, I mean, I think we can all acknowledge this reality, right? Few orgs, few organizations have a complete inventory of APIs. If you ask people how many APIs they have, it's a hard question to answer. And then we didn't talk about API gateways, but I've definitely seen the case where people have an API gateway or an API management tool. I was just talking about Azure's APM API management tool, and they believe that they know all their APIs because they're all in the gateway, like it's a self-fulfilling problem, right? I put all the APIs I know about in the gateway, so therefore, they're all the APIs I know about, which creates a gap there as well, yeah. Right, exactly, yeah. Okay, anything else about that myth that you wanted to cover, Tejpal? So I think the second point, and we touched upon it, so you have to classify, maybe just like the data you classify, you have to classify your API, what are in-built or in-house developed, what are the cart, what are the orphan, what are the shadow, what are the zombie, and all those things we talk about. So you need to have a clear visibility on those ones, and I think that is the important piece of it. That's the reality. You've got to have those inventory in place. Yeah, yeah, agreed, agreed. So let's talk about the second myth here, also one that kind of came up in our previous conversations, that our APIs don't expose sensitive data. And you talked about this idea that we're doing all our communication over HTTPS, so therefore, the data is not exposed, which is, I think, falls into that first category, belief that encryption solves everything. Yeah, I don't know if you, is there more you want to say about that? Because that one's an interesting reason for this myth to persist. Yeah, actually, there's two, multiple four answers or the idea behind it. So one, if I'm using HTTPS, that's good, I'm secure. But underneath that, if you go deeper, what protocols are you using? TS 1.2 or SSL, what are we using here? So that is another aspect of it, but that more on the configuration side of it, but definitely, that is something that makes sure that you are just building the API and publishing is not enough. Yeah, one of the other encryption-related conversations that comes up sometimes is that, so the data is encrypted in transit with HTTPS, fine. It's encrypted at rest in the data store, say it's a database, and therefore, it's always encrypted. And what I find that people don't think about is that encryption as a technology, like that data is designed to be decrypted at some point, you're offering a service. And so somewhere there's a user or a consumer of that service who is going to get that data unencrypted. And that becomes the attack vector. And so we talked about unauthenticated endpoints. If you have encrypted data and you have encrypted transit, but the API endpoint accessing that data provides no authentication or authorization, then your encryption isn't helping. You just have to connect, you've just built a service that shares the data. So I think that is one of the reasons that this myth persists, is a belief that encryption solves everything, yeah. I do also think there's this legacy web application mindset. People have forgotten that APIs are, or they haven't learned yet that APIs are so prevalent. They think in terms of the web application, what a human being sees and not what can be accessed via those APIs. And so if I don't see sensitive data on the webpage, in the web application, then it's not exposed. But of course, we talked about examples of where, data might be exposed by an API that isn't exposed in the web application itself. Absolutely, yeah, absolutely. Yeah, yeah. So what's the reality here? When we talk about sensitive data and APIs, what do you see as the reality that people should know that sort of debunks this myth? Sorry, I didn't get it, what is it? Oh, sorry. I was asking you what you see as the reality that debunks this myth. We've got some examples on the slide, but what do people need to know about sensitive data in their APIs? Yeah, so I think the first bullet point is very well said, that APIs are designed to share information, the data, right? And then you are also, when you're building the API, you are, let's talk about the logging. Are you logging your applications or the information on the API? It might be risky because you are logging the sensitive information. So now you are not only transmitting the information over the internet through the API, but are you logging that information? As the industry standard says, you must log it. But are you logging the sensitive data over there? Yeah, yeah. Or whether or not, are you masking it or you're not at all logging it, for an example, username password, things like that. So it's a very common, I would say, the quality gates you've got to put in. And then API, and sometime another point is I say, oh, if I have API, not many people can touch it. And when people can't see it, touch it, they cannot be vulnerable. Or what, like to your point, what I see only that can be vulnerable, but I don't see it cannot be vulnerable. But that's not the case, that is not the reality. Yeah. Undocumented legacy API is risky, that's very true. You got to make sure that, we have been talking about the documented and legacy. So everything should be visible and everything, every API endpoint should be talked about. Yeah. And I want to combine the first two bullet points there. I think actually you can combine to an interesting conclusion, right? So as you said, APIs are designed to share data. That's what they're good at. And developers don't know what's sensitive and what's not. As a developer, I'm not the expert in what data should be shared and what shouldn't inside your API or application. And so as a consequence, if you give me a requirement to build an API that pulls data from a particular data store most likely I'm going to give you all of the data because eventually you're going to ask me for more of it instead of giving you only the data that you asked for and then let the application layer somewhere else try and figure out what to show and whatnot. As a consequence, you end up with APIs that share too much data. That's a very important point you brought up, yeah. All right, let's move on to myth number three here. Myth number three is about the other tools that customers have, you know, WAFs, web application firewalls, API gateways, you know, these tools, the myth is that these tools provide API security. And I think, you know, why do you think this myth persists? So when we have the web app and let's say on underneath the APIs that they are, and the myth is basically say, I have WAF, which is my shield. So it's going to stop everything, yeah. Everything coming from outside world into my server is going to stop it. An API gateway is going to play a traffic cop who is going to make sure that if anything is passed through there from the WAF, API gateway is making sure that nothing else falls through the cracks. I think that is kind of a myth or perception. Yeah, yeah. Well, I think- That's not true. Yeah, there's some, what I've called capability confusion here, right? So WAFs, as you said, they are a security tool, right? So I've got this shield that's supposed to stop things coming in, bad things. It's a security tool. It seems totally reasonable, I would expect it to do that. And then the API gateways, they do offer some security features. If you want to implement centralized, manage authentication authorization, API gateway is a great tool for that. Yeah. But the reality is that we know from real world examples, from open source testing tools, that web application firewalls don't do a great job of stopping API attacks. They don't understand the protocols. They don't parse the requests in full, and there again, they're deployed at that perimeter and APIs aren't always at the perimeter. And then the API gateways, again, they do a great job at authentication authorization, but they're not designed to detect and block attacks. It's a different tool. And so we see this myth with good reason persisting, but with reality, hopefully, people move on from it. Absolutely, yeah, absolutely. All right, so myth number four, detection is the same as prevention. I love this one because it's really about the people who actually have to do something with the tools and the data, right? So if you have a tool that detects attacks and tells you about them, what's the end result? What do you, you as a security practitioner, what do you end up having to do in that situation? So knowing there is a vulnerability is one piece of the information. I can say that, okay, I have this API and there's a vulnerability, but how I'm taking care of it, how I'm remediating it, and how I am making sure that I'm preventing it to happening again in the future. So it goes with the kind of a twofold. One is to make sure that you go through all the, make sure that you know if there are any vulnerabilities or run the scan or other mechanism, threat modeling, things like that. Make sure that you detect any attack, maybe in the runtime in this scenario, and also have the mechanism to prevent it from happening. Because detection is something which is too late if by the time you get to know. Right. And prevention is that you are preventing it to happening. So like before it happens, you are preventing it. So I think that is the important piece in this scenario. Yeah. I mean, you're essentially saying detection is always, it's always after the attack, right? Even if the point of detection is real time, the point at which you as a practitioner receive and see that detected event, the attack has already occurred. And so at that point, you're moving into forensics, right? You're finding out, did that attack succeed? You've got to go do the work to find out. And then if it did succeed, raise an incident, et cetera, et cetera. So if you're not actually blocking those attacks in real time, you're creating a lot of work, but you're also, it's not the same thing. It's two different mechanisms, if you will. Right. Yeah. And then, you know, like in the detect multiple tools, you can get a report saying, hey, these many threats I have detected. But by the time you're reading the report and it's saying it's a fancy looking report where it says that 10 threats are detected. But while you're reading the report, something else is, you know, compromising over there. So you've got to prevent it before that report comes to your hand. Yeah, exactly. Exactly. Yeah, that makes perfect sense. All right. For the last myth we have, current security testing tools are not enough. So we're shifting a little bit from, you know, attack detection to security testing. And, you know, this is a tough one because there are a lot of tools out there that claim to do a lot of things around security testing. But are they doing the job, you know, or why, you know, we should say, if this is a myth, why does this myth continue to persist? Yeah, I think I will just pick on the word shift left. And I think that it's still very valid in the sense that if you are not thinking about security from the beginning of the time you're designing your API, you've got to think about how your threat model look like. And why the dependency on the tools itself. So you have a kind of blueprint of API, what is coming in, what is being processed, what is going out, what the authorization looks like, things like that. So you have a kind of blueprint of those ones. So, and then definitely that's kind of first step when you design any solution, whether it's an API or anything else in security scenario. So when you, you still have to, you still have to do the vulnerability scanning, whatever tool is your favorite tool, you want to do it, but you are minimizing the chances of having, minimizing chances of having finding vulnerability at that scenario. So if we look at the entire SDLC, you have to put all the quality gates from design through, I would say the production or operation. So in the end, if I, in the beginning, if I put threat modeling, in the end I put, let's say DAST or pen testing, and you have to really make sure that you are minimized, you have the very minimum or no finding in the DAST or penetration side of it. And you have more finding when you're doing the threat modeling. Yeah. Yeah. I mean, I think, I think you're, you're pointing out that, you know, shifting left is good, but as you said, you have to look at the whole life cycle. So shift left is almost, you know what I always think of here, actually, you know, the phrase, there's a phrase curiosity killed the cat, which people say all the time, right? When someone asks too many questions, oh, you know, curiosity killed the cat. But that phrase actually, that's only half the phrase. The whole phrase is something like curiosity killed the cat, but satisfaction brought it back. Like it's actually not, you know, this sort of, it's not, it's not an attack on curiosity. And shift left is the same. The phrase actually should be shift left, shield right. Like you need to do both. Yes. Yes. If all you do is shift left, you're missing out on, you know, you're not going to find every vulnerability and you're going to miss attacks because you're not shielding right. Exactly. Which brings me to one of the things we talked about in the, when we, when we were preparing for this webinar, which is this idea, you know, if you ask the question, does finding vulnerabilities actually reduce risk, right? I found a thousand vulnerabilities. Have I actually reduced any risk in my environment at that point? Not necessarily. The answer has to be no, because you've, you've found them, but you haven't done anything about it. In order to reduce risk, you've got to actually fix or address those vulnerabilities in some way. And so, you know, if you're implementing security testing, you better make sure that you can actually address the findings. Otherwise you're, you're creating vanity metrics, so to speak. Okay. So those are the myths that we wanted to talk about. From there, I thought it was worthwhile to move off of the myth into sort of what are the key principles for modern API security? And I don't think any of these should be a surprise because, you know, they're natural conclusions from some of the topics we've already been talking about. But when we look at building an API security program or addressing API security, you know, there are a number of sort of key principles that we want to pay attention to. And interestingly enough, you know, we already had NIST 800 228 come up in this conversation. You could think, you know, that NIST document is a very specific prescriptive controls you should apply. These are more like high-level principles of, you know, objectives, if you will, that you want to accomplish. So, Tejpal, are any of these, do you want to pick out one of these that you think is sort of your favorite or most important? Yeah, if I have to pick, I'll pick on the connect to revenue. It's a very interesting one. API security must be connected to the business and business flows that generates revenue. So you have, and it's very, very interesting that caught my attention, actually. So you have the, how much business value the API is bringing. Say, suppose you have payment gateway or you have a critical business operation, those are happening on the API, on those, through those API channels. And then that is basically driving the dollar value, basically. And you don't want to have any compromise in that channel. And then you want to make sure that your business process is intact. Because if business process is broken in that scenario, may it be vulnerable or exploitable or any other, even the logical flaw may be, it have the impact on the revenue. Yeah, yeah. I think that might be the one I would have picked as well, because it's, the other principles here, you have to discover everything. It's not just the inventory of APIs, but also the sensitive data and risk assessment. We talked about that one. Blocking in real time, we talked about. We didn't talk about identifying abuse, so maybe we will in a minute. But operating at scale, that seems fairly obvious as a key principle. You've got to make sure that the tools you implement operate in your environment. Connecting to revenue is a bit of an outlier because in most cases, what we see are application security teams that have a mission to secure the applications, but don't necessarily have a clear connection to how revenue is generated. They can't necessarily articulate how much revenue they've protected. And it's a difficult problem to solve. It's a challenge. But if you can build an API security program that has that connection to revenue, you'll get much greater attention from the business leadership about what you're doing. And it makes a big difference, for sure. Absolutely, yeah. Yeah. So this API abuse topic though, I think is worth mentioning, because we didn't talk about specific attacks so much. We talked in generalities about attack types, but there are two big buckets of attacks. There are sort of traditional attacks that you might recognize like SQL injection or remote code execution or path traversal, but there's this growing trend in attacks that are behavior-based, that are leveraging the business logic inside of those applications to exploit. And maybe we touched on those a little bit with sort of the authentication authorization challenges. But API security absolutely requires the ability to identify and manage API abuse as well. All right. So I think we're towards the end of the deck here. I'm gonna take a look at the questions that we have. If you have questions for us, feel free to put them into the chat or the comments in LinkedIn, and we'll do our best to answer them as we go. So we've got one question here. Are you seeing rate-limiting bypass attacks? I'll start with that question because I can speak from what we see in the Wallarm platform itself across our customer base in terms of attacks, and then Tejpal, you can jump in if you want to comment. So in terms of rate-limiting, usually what we see are attacks that are designed to avoid rate limits. Specifically around like account takeovers. So if I have a big database of compromised credentials that I wanna test or I wanna use, if I just send those one credential at a time or multiple credentials at a time all at once, I'm gonna hit a rate limit in a lot of cases. If I don't hit a rate limit, I also might trigger rate-based detection mechanisms. So we do see sort of so-called low and slow attacks. One login attempt per hour, one login attempt per day, it's gonna take me a lot longer to get through that database but I'm not gonna be stopped. So I would say, yes, we definitely see those. Yeah. Yeah, okay. Tejpal, anything you wanted to add to that one? No, I think you've covered it, yeah. Okay, cool. There's one other question here. I think it's more of a comment about abuse connecting to revenue with the business's key to getting the funding. Oh, so the comment here is that if you can connect API abuse to revenue, you're more likely to get funding for your API security project. Tejpal, you probably have more experience getting funding for projects than I do. Do you wanna comment on that one? That's a really interesting question. Thank you for asking that question. I think there's two scenarios. One is the abuse could be in the business logic. You can have the API 100 per secure lock and loaded. There's no problem from the security perspective as you can think, but you can still have the abuse of business logic. Let's say calculating from one cent to $1. I'm just giving the one simple example. And other analogy I would give you is that whenever any breach happens, you always get funding. Yes, yeah. It is an unfortunate truth. It's unfortunate true, it happens. But I think it's a very good matrix to have that. It not only help business to stay the weak point or where the cracks are in the business logic or the configuration in the API. And it's a good matrix. I would say the KRI to share with the leadership or the stakeholders saying, these are the areas that we need to improve on or how we can make sure that we are not losing money just because of this abuse. If the dollar value there, but at the same time, reputation and other things is also factors in these scenarios. Yeah, and you mentioned KRIs there. You mean like a key risk indicator, yeah? Yes, yes, yes. Yeah, yeah, yeah. Yeah, I think that's important. It's true, getting funding is absolutely one of the CISO's challenges. In fact, you could argue it's the CISO's primary job is to understand what risks and then get funding to address them. Yeah, cool. Okay, any other questions from anyone in the audience? I don't see any new ones coming in. We did have a few questions throughout, which I really appreciate. And, okay, I've got two, sorry. I see two additional questions now. Do you see AI bots used in attacks? I think the answer there, that's a challenging one. The answer is yes. The harder question is how can we identify them effectively, especially when we're talking about API attacks? Because APIs are built to be used programmatically. So what's the difference between a legitimate user and a bot, first of all? There isn't one, because legitimate users will interact programmatically. The only difference is malicious intent, really. And then AI bots, well, they're going to look like other bots, right? In terms of APIs, because they're interacting with the APIs in a similar way. And there was another question in there, but I think it got answered about documentation for Wallarm. So I think we're good on questions at this point. All right. With that, I think we're done with this webinar. I want to thank everyone for joining us. I want to thank you, Tejpal, in particular, for joining us and helping to present and chat about this topic. It was an interesting and worthwhile topic. And we look forward to seeing folks on the next webinar that we do that's coming up. So thank you very much. Thank you. Thanks, everybody. Thanks, Jim. Thanks, Brandon. Thanks, everyone. Thanks.
