Hello and welcome to another KuppingerCole webinar. My name is Alexei Balaganski. I'm the a lead analyst here at KuppingerCole. And today we are talking about the future of API security, understanding the current trends, challenges, and innovations in the market. Since there is no second speaker in today's webinar, our agenda is pretty simple.
We just, but before we dive into that, let's just spend a minute on the housekeeping rules. First of all, you are all muted centrally, so you don't have to worry about microphone. We will run a poll in the beginning, and then we will discuss the results later. And we will have enough time at the end of the webinar for your questions, but you are very welcome to submit them at any time, as soon as you have a question, using the Q&A panel on the right side of your browser window.
And of course, we are recording this, and we will make the recording and the slides available on our website, www.kubernetecore.com, probably tomorrow. You will get a notification about it. So let's start with a quick poll. I only have one question for you. Does your organization already have a defined API security strategy? And while we give our attendees a minute to cut their words, just to explain the options. So obviously, some of you probably already have API security under control. You know what to do, you know how to do it. And I'm wondering why you are attending this webinar.
Still flattered that you are interested in Kubernetec Core's research on that subject. If you are working on it, then again, you're very welcome. This is exactly the right kind of content we want to share with you. If you believe you have APIs covered through some other kind of solution, for example, through a web application firewall, well, let's agree to disagree. And finally, if you believe you don't need an API security strategy at all, well, again, I would really love to talk to you after the webinar.
So, so far, the vast majority of attendees are basically saying they are working on it, which is great, which is exactly what you are supposed to be doing, because API security is kind of a big deal nowadays. It took a few years for the world to actually sit up and take notice that something bad is happening in that area.
But now, after a string of really well-publicized and large-scale API security breaches, everyone at least knows they have to do something, and it's great that some of those people are actually attending our webinar to find out exactly how to solve the challenge. Okay, I believe you don't have to wait any longer. Over 90% of our attendees are working on the API security strategy, and I would be glad to share KuppingerCole's findings in that area with you today. Thank you. Can we please close the poll?
Okay, I guess let's continue and start by quickly explaining why are we so worried about APIs anyway. So APIs are originally an obscure technical term, but nowadays, APIs are just simply everywhere. Everybody's talking about them, and everybody is dependent on them. Why?
Oh, because APIs define how different IT systems communicate. And now, the vast majority of the world's business is basically IT systems communicating over the internet. And creating APIs with specific standards and protocols makes this communication easier. And as we started to find out recently, a lapse in securing API communications can lead to very, very bad consequences for the business, up to upgrading the entire business process to a halt, especially for a company where APIs basically make the core of the digital product. Speaking of companies like Google or Meta or OpenAI or Microsoft.
One thing we can definitely identify in the recent one or two years is the rapid growth in complexity, both in API technology and API security. Why?
Well, the next slide. Well, because APIs are dramatically growing in importance. We used to use them 20 years ago just to ensure interoperability between third-party software applications.
Nowadays, it's much more than that. APIs are everywhere. They are in your mobile phone, they are in your computer, they are in every industrial device. They are in your car, especially if it's an electric car. And of course, APIs power clouds, and APIs power charge abilities, the MLMs, the AI hubs of the modern digital era. The demand to deliver business logic through a standardized API interface is growing, but also the variety of those demands is growing. So new API standards and protocols are emerging, or some existing protocols are being repurposed.
Five years ago, nobody would even call Kafka, for example, an API endpoint. Nowadays, it's absolutely a part of a lot of modern application architectures.
Therefore, API management changes profoundly. And of course, securing that variety of protocols and standards is becoming more and more complicated. And on top of that, we have the growing complexity of compliance regulations, because as more and more countries and geographies and industries are introducing different regulatory frameworks, they all have direct influence on securing APIs, because again, APIs are just tubes where sensitive data is flowing. As I mentioned, APIs have dramatically grown in complexity.
You could call it a Cambrian explosion in a way, but yeah, basically we have, we observe a lot of new standards and technologies beyond the most traditional RESTful APIs. We have new deployment scenarios everywhere from multi-cloud to microservices, again, mobile, AI, and even AI. Non-human identities communicating over APIs and so on.
As I mentioned, new frameworks, new business requirements, and the crucial point here is that those complex business requirements increase the complexity of the API business logic, meaning that things that happen within an API interface can no longer be reduced to a number of simple variable rules. Those tools which you're hoping probably to reuse for securing your APIs five years ago now are hopelessly outdated. So what to do? Where do we even start with API security?
Well, there are some really, really useful developments recently. Of course, the OWASP project has been recently working on updating their top 10 API security risks list. And just earlier this year, we have discussed the changes in a set of analyst chats, for example, a KuppingerCole podcast. So I recommend going back and watching them if you want to know more. But one thing I want to highlight here, those top API security risks, almost none of those are related to specific narrow set of technologies, be it HTTP or a database or authentication or something else. This is all together.
Some of those points, you might even argue, do not fall under cybersecurity at all. Like why would you put access management under the umbrella of cybersecurity?
Well, if you are still thinking like that, you are definitely wrong. And of course, modern cybersecurity is impossible without strong identity management. Some of those issues are clearly purely business logic.
Again, you cannot prevent broken object property level issues with just a web application firewall because that firewall has to know what's actually happening within that API payload. And finally, some of those issues relate to processes more than technologies. For example, the number nine, improper inventory management. This is where a lot of companies fail because if you do not know what you are protecting, like how do you know whether it's actually safe? So most of these risks are consequences of bad design decisions, development practices, and insufficiently secured business processes.
And all of that nowadays falls under the umbrella of API security. So what are the real risks you will be dealing with?
Of course, those of us top 10 are still crucial and relevant, but there are hundreds of others. And most of the people within your company would probably think in a slightly different language. How do you approach API publishing and development safely yet efficiently in general? Regardless of cybersecurity specifically. How do you even know all the APIs you already have? Your own and third-party ones. How do we monitor all those API activities and how do we know, how do we stay on top of all the anomalous and suspicious activities happening in real time?
How do we extend security towards development processes? How do we shift left, if you will? How do we respond to a data breach after it already has occurred? And finally, last but not least, how do we keep the compliance audience happy? All of this, again, falls under API risks and you have to cover it with API security solutions. So on the next slide, I attempted to illustrate some of the basic areas which now fall under the scope of modern API security.
Again, it all starts with discovery and classification. You have to know what you have.
And this, of course, includes the third-party APIs as well, especially those because, yeah, sure, you might have 10 or 50 or even 500 APIs developed by your internal application team, but you might have another 5,000 everywhere within each of your cloud accounts, within every IoT device, or even a connected printer in your office, or a camera, or a mobile phone which is used to access your application, and so on. All of those APIs have to be at least accounted for.
Of course, you have to enforce consistent and fine-grained access policies because it's, I mean, APIs are, after all, all about doing something to your data and the data is almost always sensitive. In different ways. You have to ensure that the data is validated all the time because incorrectly formatted API requests can just break the entire business logic of your application and grind your entire digital business to a halt. You have to ensure resilience against the quote-unquote general purpose exploits and abuses such as bots and ransomware and DDoS attacks, and so on.
You have to ensure that the data stays secure, at rest, in transit, and everywhere in between. You have to know what's going on, so you have to ensure not just visibility, but also anomaly detection, and ideally even automated mitigation of those suspicious and malicious activities in real time. And finally, closing the loop, you have to stay on top of secure development because the earlier you can ensure that your API has fewer vulnerabilities or as few vulnerabilities as possible, of course, the less you have to work later.
And ideally, your API security design should even start before you write the first line of code. With APIs, you always start with a specification, and that specification in itself is a great construction site for ensuring that your API will remain secure in the future. And this is where we are coming to the recently published leadership compass on API security and management, where we went out and scanned the market and tried to identify all the relevant vendors, the capabilities, and basically rank them according to their ability to deliver.
This is our fourth edition, the fourth update of the leadership compass covering API security. The first one was published back in 2015. And if I remember correctly, back then, we have been struggling to find enough vendors calling themselves API security companies. I still fondly remember the first time I met someone who called themselves an API security expert. It was not that long ago. In the latest edition, we have 40 different vendors, including 25 where we have sufficient data to evaluate and rank them, and the rest are just mentioned as vendors to watch. So where do we begin?
We begin with identifying the key evaluation criteria, like how to even measure the efficiency and the scope of API security solutions. Well, first of all, we have to ensure that they actually do cover the entire API lifecycle management from design and development, testing, runtime deployment. And the entirety of the production lifecycle and then eventual retirement to an API endpoint. They have to support a broad range of deployment scenarios and integration capabilities, including clouds and multi-clouds, distributed microservice-based solutions.
And of course, they have to be able to talk to a lot of third-party tools. They have to provide sufficient developer-oriented capabilities, portals and other tools, helping not just onboard developers to consume APIs easier and in a more secure manner, but also help them develop their APIs for more security. So talking about DevOps and DevSecOps here.
Of course, we have to ensure that those tools do identity and access control for APIs. It's not just strong authentication and access policies, it's ensuring that these capabilities work consistently across that wide variety of environments and API gateways and service meshes and microservices, you name them. They have to be able to identify API vulnerabilities proactively by analyzing the codes, the endpoints, the infrastructure and so on. And ideally also harden, like eliminate those vulnerabilities.
They have to be able to stay on top of what's going on in real time, not just see into API transactions, but understand what's going on, identify problems and remediate them. They have to ensure that APIs remain secure and available, if you will, against attacks, threats, data breaches and exploits. And finally, they have to not be, they have to not stand in the way. They have to ensure that they do not cause too much performance overhead. And in every leadership compass, we focus on multiple dimensions.
We try to measure how each vendor delivers the core functionality, of course, but also how securely is this functionality exposed to consumers, the users, the admins and so on. How easy it is to deployment and how broad is the supported range of deployment scenarios. How quickly can they be integrated with third party solutions and how easy they are to deploy and operate. And of course, we look at the vendor capabilities more in general to understand, can this vendor keep up with the latest developments and deliver the latest innovations as the market changes?
Do they have a strong market presence? Do they have a lot of customers across different geographies? Do they have a strong ecosystem with partners and resellers and support services and so on? And finally, like, do they have enough money to survive in this highly competitive market? And this time, as I mentioned, we have managed to identify about 40 different vendors and 25 of those have actually agreed to spend their time and resources to demonstrate their solutions to us or to answer a lot of our questions.
And then we were able to crunch all the numbers and basically convert the inputs into our ratings. As you can see, the list is really diverse. We have large veteran vendors like Red Hat and Google and Purva and Broadcom and so on. We have some really small boutique vendors like 42Crunch or Purity, which of all like Airlock, companies that only focus on solving specific problem, but doing it really well. And of course, we have some companies which some people would not even consider API security vendors. Like Purity, for example, which is only doing access management or cloud entity.
And yet, without doing access management for APIs, security is completely, the whole issue of API security is completely moot. And of course, we have other vendors to mention like every other large cloud vendor has something to offer with API security tools and some other companies who are unable to participate, but we believe they were worth mentioning anyway. And as a cherry on top, I would like to show you a sample detail page, like how the kind of information you would offer to our readers or for every analyzed vendor. So we identify those eight functional areas.
We measure the vendor's capabilities along each of those areas, and we create a spider chart. So you could see, for example, that this particular vendor does not focus a lot on identity and access control, but they do focus a lot on developers and vulnerability management. This is basically what this company does. They have an extremely sophisticated solution for proactive hardening of API specifications. And for each of the vendors covered, you will find this information. And of course, we will go through that in a minute.
And again, I want to remind you that you have to, or you have the ability to submit your questions at any time and we will address them later. So just to remind you, we have 25 vendors and looking at the overall leaders chart, basically on the right, you see the vendors with the highest overall marks. And on the left, those who are more niche and boutique or have smaller market patterns, basically their ratings are the lowest. You would probably still be a little bit confused.
Like, isn't it comparing apples to oranges? Like, how can you compare a company like Cerberus, which is only focusing on externalizing policy-based access management with Google or Imperva, like a pure API security vendor?
And yes, you would be right in a way. This is comparing apples to oranges. Unfortunately, this is the limitation of our core format, which is basically static. And this is exactly the reason why we decided to expand on that and make our leadership compasses more interactive and more usable for people who do not have time to read through like 100 pages of a report and only want to quickly find solutions more suitable for their specific use cases. And this is where we are talking about grouping a call open select. You've probably seen this product mentioned in our earlier webinars as well.
And we already have multiple subjects, some multiple topics covered. But today, really like just a couple of hours before this webinar, we finally have grouping a call open select available for API security as well. And this is exactly what I would like to show you in a live demo. Fingers crossed it works. This is grouping a call open select. I have it open in the browser on my second monitor. This is a real browser. This is a real application. You can find it directly on the grouping a call website under grouping a call open select menu.
And as you can see, we have a list of various topics we have covered. And API security management has been added today. What you get when you sign up and signing up is completely free. You only have to create an account or if you already have one, just proceed straight to open select. You will have a summary of the data from the leadership compass, kind of bite-sized and compressed and available for you as a website, like the highlights from the market coverage, the whole definition of the market, like what's going on, why are we covering it? How is it developing?
You can probably even recognize some of the diagrams. We have some additional questions not covered in the leadership compass at all. Like what should be your prerequisites when you are choosing the right API security solution for your organization? Where do you start? Like what technical requirements you have to attend before even going into this role to this world?
Use cases, we have identified some common use cases, like why would you want to deploy API security? Surely for different companies from different industries, the requirements will be vastly different as well. So for example, we have identified that API discovery and the risk posture is something which a lot of companies start with. This is like the low hanging fruit. And at the same time, the crucial prerequisite for any sensible API security architecture, you have to start knowing what you have across your API landscape.
And we could help you identify exactly the solutions which would be the best fitting tools for that. On the other hand, if you are, for example, serving your application or business logic through an API, and it's all about retail, for example, or something which involves sensitive data, which you would want to protect as much as possible, you might be more interested in protecting your productive APIs from accounting over breaches and other threats. Since the core requirements and priorities would be different, the list of vendors fitting for this use case would be different as well.
Cloud native application development, again, if you are dealing with thousands of containers and microservices, you probably don't want to have a traditional API gateway, you would need something else. You want compliance, fine, we have you covered with that. You want business continuity, again, you want to start developing your APIs securely by design.
And again, we have those use cases identified. And of course, we have all those individual capabilities explained. And finally, you can go and start comparing your solutions. So basically, if you choose a specific use case, it will translate into this particular combination of requirements.
Like I, as an author of this report, believe that to enable you to deliver your API securely, a vendor must be able to deliver on this specific critical areas. First, and then of course, it has to have a lot of sensible development tools. And of course, it still has to cover API vulnerability management. And you can see which solutions our website identifies as the most fitting because we know how well each vendor fares on the spider chart. And we basically compare those two charts and give you the ones with the best overlapping area.
And of course, when you change to a different use case, the list will change because the requirements will change as well. And you can see that, for example, for account takeover and breach prevention, we don't care about development tools at all. But we do care a lot about analytics and security intelligence and identity access controls and so on. And for each vendor, you can just click and find out more. We will have all the detailed information, not just the ratings from the leadership compass, but some more information. Is it budget friendly or is it more focused for enterprise customers?
What's the company size? Like they are targeting, not because not the vendor size, but like what's the market segment they are targeting primarily. Which languages do they provide support in and so on.
Of course, we are still working and expanding this section and we will add more. For example, for some other topics, we already have interviews with the product managers. We have analysts explaining their findings in writing or again as videos. We have downloadable materials supplied by vendors to help you understand their solutions better and so on and so forth. And of course you can just browse all the solutions, see all the information about each vendor.
And really we have a lot of different companies from tiny open source projects, which only do one thing, but like exceptionally well like servers. Or we have companies like Broadcom or Axway, which are industry giants and they offer huge service portfolios, not just around API security, but in the adjacent areas as well. You can choose or you can, I'm sorry. You can alter your results.
Again, for example, you could say you only want to have pure play API security solutions and you do not care about API management. You can do that as well. You can filter by other capabilities. And finally, you can basically create a comparison but say, okay, I want to see what's going on between WSL2 and forum systems and layer seven. And you will see all the capabilities listed together, ratings, friends and challenges. We will add more videos soon as well. And of course you can export these comparisons either as a PDF to download or just to send a link to a colleague.
Hey, have a look. This is kind of helpful.
So this, I guess, concludes our short demo. We have OpenSelect available for other topics as well. Attack Service Management has been published earlier today and we have other topics published earlier. I recommend you go have a look whether you're interested in API security or some other cybersecurity or identity and access management topics. We will be adding more early next year. And of course we are focused on developing this product strategically to add more interaction, to add more non-textual content for you to consume at your own pace, like videos.
And of course, sneak peek, watch this space. We are working hard on integrating artificial intelligence capabilities into this area as well. And with that, I would want to give you some parting thoughts. So what is the future of API security? API security is already mind-bogglingly complex and it will only grow in complexity simply because APIs are no longer those easy to understand, primitive and completely insecure RESTful APIs.
No, the APIs are evolving. The standards architecture protocols are emerging. You can no longer protect them sufficiently with quote-unquote traditional tools. Forget those tools. You have to look for specific and also quite complex solutions which only focus on API from the business logic perspective. The future is uncertain. Some people believe API security will grow that like into basically incorporating the rest of cybersecurity because well, you have to cover data protection. You have to cover access management. You have to cover bot protection and DDoS.
You have to cover basically every other area of existing area of cybersecurity. Does it mean that API security will become synonymous to cybersecurity in general? Probably not, but it might lead to further fragmentation of the market. We will be, of course, watching this space. We will be publishing updates for our coverage. And of course, we offer you much more, much more current and relevant insights in between on those leadership compass publishing life cycles. What can you do to be prepared to this future uncertainty?
Well, first of all, you have to understand that API security has to apply across the entire life cycle. You should not be choosing between shifting left or shifting right. You have to do both and everything in between. If you want to actually be able to stay on top of this, you have to have it automated and intelligent because human analysts just cannot keep up. It's much more complicated, much more noise generating than even traditional scene solutions. So you have to accept intelligent automation as the core capability of every API security solution.
And finally, it's probably still impossible to buy an entire API security platform from one hand. And by the way, like with all the recent changes, like for example, Empower, a leading API security vendor just being acquired by TARES. We do have a lot of interesting developments, consolidation and capabilities happening as well. But so far, you probably have to build your own API security fabric. If you are struggling with that, we are here to help you. And finally, we do have some additional reading material on our website.
I recommend you visit and also watch our analyst chat podcast on the future of API security as well. And again, let me remind you, you have the last chance to submit your questions. And so far, I don't have, I don't see any. Just we'll use the last remaining minute to plug our upcoming European Identity Cloud Conference, which will take place in Berlin next June. This is our flagship event.
And although it's not specifically focusing on API security, we will do, we will offer a lot of adjacent topics covered from, again, AI and next generation identity and all the trends and innovation in digital transformation. A lot of things to cover. Hope to see you there. It will be our 17th, I think, year. And if it will be your first, I assure you it won't be your last. So definitely see you there. And with that, thank you very much. And if you do not have any questions now, you can always reach us later by email or using the inquiry form on our website. Thank you very much.
Have a nice day.
