Okay. So yes, if you've even attended this track before, you've probably already seen some of my colleagues introducing the format, the leadership compass earlier. I will go through a similar story quickly focusing on the market for a p security solutions. So I guess if you just start with the first question, like what are APIs?
We don't, of course we don't have to delve deep into the technicalities, but my only point here, and by the way, can I have my slides on the second screen as well. My point here that APIs are very old and APIs are, are very, were invented for a very simple principle to make application development easier. And at no point in that long history, security was a big concern for some time back in the sixties or nineties or even the early notice, it has worked reasonably well.
But then came the cloud, then came the iPhones and other mobile devices and nowadays basically we have this Cambrian explosion of complexity and just innumerable use cases where APIs are forming this backbone of modern digital economy.
So why are API import APIs important?
Yes, APIs are simply put everywhere they are at homes and in the mobile devices, in the corporate networks, in any IT environment. And as you can see they started small they, but in on the on the way basically they've jumped, started several really important trends such as Web 2.0 and the whole digital economy if you will are, and they turned basically data exchange into a lot of successful business models.
And now we know that API traffic is basically constituting a large and in several areas, even the majority of the entire web traffic and of course the same leads to a major increase in attacks.
What we see now today is that the businesses, modern digital businesses demand even more sophisticated API standards protocols or use cases and so on. They of course have to deal with much stricter compliance regulations. They have to be prepared for much more direct consequences for non-compliance. And well basically somehow APIs became the backbone of modern digital business.
And on that way people just kind of decided that finally it is the time to start thinking about securing that property. For me personally, this whole API security research started in 2015, something like around 10 years ago when I first actually met the, the company calling themselves an API security vendor. As you can, if you will see in a minute now there are dozens of vendors. There are some vendors who are already valu evaluated at more than a billion dollar focusing specifically on API security. So it is an extremely successful, a diverse and quickly evolving market.
Why?
Well simply because as I said, API has be, APIs have become extremely complicated. There are no longer this traditional REST APIs which are basically are are natural extension of the web protocols. There are new standards, GraphQL, G-R-P-C-M-Q-T-T even and other protocols which like five years ago nobody would even consider a ki a kind of API. There are new deployment scenarios, multi-cloud microservices and so on.
There are many more regulatory frameworks and of course there are much more complex business requirements of course for those all throughout all those years, there were people who would just say, but we have a rough web application firewall. So PR secure r and t, well not really even back then, the biggest drawback of any traditional VAV was that they never knew anything about the business logic behind the API. So sure they can, they can protect your network packets.
They can probably protect or some basic attacks from, from some basic attacks, but they would never know how your API is actually supposed to behave to then and to understand what, what's going on, what's actually incorrect at the moment.
Over those years there have been some really interesting developments. Of course oasp now has their own top 10 API security risks list and it was even recently updated last year. And as you can see or the actual issues, the biggest risks they attribute to a a p security are not really about like network security.
Basically they are all consequences of bad design decisions and development practices. Some are directly related to improper access controls. Some are caused by unsafe consumptions of api. That is are you just don't know who is actually accessing your API or or do you even have or how many APIs do you even have some? So maybe just two, three of these top 10 securities actually still addressable by traditional security tools. The majority requires completely different new types of solutions.
And of course, even if there is a vendor who would say, but our tool like definitely addresses all those top 10 risks, that's by far not enough. The problem is of course that real API risks are not even technical. They are direct consequences of your business challenges and risks. So how do you implement APIs quickly but safely because it has to be done yesterday.
How do we ensure that our APIs stay up even when they are hit by huge volumes of traffic? How do we know what actually happens with our APIs at any moment of time, ideally at scale?
How do we ensure that people who are developing them actually know anything about security at all? And ideally, how do we solve those problem, those problems before they actually happen because we have to actually show our auditors that we know what we are doing. So those are hundreds if not thousands of risks are the long tail after the top 10 though I have been trying to formulate the kind of the entire scope of modern repair security.
And if you look at this picture, you could probably say but, but isn't it like the entirety of cybersecurity because you have to cover the entire lifecycle of an API and APIs are basically, well they are applications as well.
You have to design a data model, you have to write some code, you have to ensure that the access is, the access model is proper. You have to validate all the data according to your business logic and some security practices. You have to, you still have to protect your traffic from the traditional network based attacks. You have to ensure that the data cannot be leaked.
So it has to be secured, for example, encrypted. And of course you have to know at any time what's going on. So isn't it like the entirety of security with some zero trust mixed in?
Just for, for the measure, and this is where we can go to our leadership compass. So we have been looking at this market since 2015 or the last one was released like at the end of 2023 I I believe it was like the, the sixth edition already.
And as you can see we have quite a few companies among the partici participants. And what's I, what I find really curious that even after at least 10 years of development, the market is still extremely turbulent. There is a huge mix of large companies like Google and Broadcom and Akamai.
There, there are, there's a lot of startups which would only focus on maybe like one or two aspects of API security and still be quite successful because they are doing it exceptionally well. Or there are some are extremely like boutique vendors who would only focus for example on securing Windows APIs or financial APIs or would only do access management. And yet those are still solutions which you should be able at least know about and consider when developing your own API security strategy.
So the key evaluation criteria somehow, I mean they are actually reflecting that diagram, which you have seen just a minute ago. So we believe that an API security solution, first of all has to know something about APIs from the conceptual perspective. It has to be aware of the entire API lifecycle management. It has to know what an API design contract is. It has to follow the development and testing and operation lifecycle according to all those specifics of APIs on the business logic and technological levels.
Of course it has to be aware of the modern architectures, the microservices service meshes, hybrid clouds, Kubernetes, you name it.
API security does not exist in the vacuum. It still is something which involves a lot of traditional API management. So it has to incorporate developer tools and portals and documentation and specific tools and tool chains to support DevOps and DevSecOps practices.
It has to, well cover identity, access control, vulnerability management, all those components are just as important for the successful API security strategy. Or I would not go deep into the pillars of our methodology because even Alejandro, my colleague just covered them earlier today. Basically we measure the performance of a vendor and the product according to specific criteria and we calculate the metrics. So as you can see there was quite a lot of vendors participating. We only rate a vendor if they actually agree to participate and then go through the entire rating process with us.
It's a really a huge mix of companies as I mentioned from tiny startups like 42 crunch to huge companies like Red Hat or and Google.
Some vendors decided not to participate fully and yet we believe they're still important enough to kind of address their existence and capabilities. So we have some more companies among vendors to watch and of course for every vendor we cover, not just the overall rating but calculate their performance according to all of those functional criteria. And this is just an example of what our vendor valuation would look like.
And of course you can access our leadership compass online and see the details for every participating vendor. And again, it's, I find it extremely important to highlight that no vendor can do everything. No API security vendor is able to cover all those eight capabilities perfectly. So there always will be some irregular shapes on the spider chart.
And this is okay, where do we go from now obviously our APIs are continuing to evolve or again, the market is far from maturity as if you following our, the recent mergers and acquisitions, even large vendors like Imperva or Nona Security, which actually included as leaders in my recent publication are already either acquired or merged into other companies. And this process goes on all the time.
Traditional tools would no longer work period. Nobody who will tell you that a V tool can properly secure APIs should be taken seriously.
You've probably heard a term V web application and API protection. It's basically a valve in disguise. It could probably work okay, but it's not a real API security solution. I will die on that hill probably.
Yes, the future is uncertain because of the complexity and sophistication or maybe API security will become so complex that it would just crumble upon its own weight and fragment into smaller segments. I hope not because that would only make the tools choice even more difficult. And of course the future of API security is automation and that are, we have to address the elephant in the room. What about generative ai? Everybody's talking about that.
Well, I just decided to ask JGPT itself, how does it see the influence of generative AI on the future of API security?
And this is what he produced. I swear to go, this is like the first picture I've created with a very simple prompt.
So yes, generative AI is a hugely disruptive factor in many senses because it'll not just affect the future of the better and more intelligent and more automated API security tools. It would also be a huge support tool for hackers and bad actors as we've discussed earlier today. But of course you have to remember that generative AI tools are actually powered by APIs themselves. So the existing a i security tools actually have now evolved even further to incorporate all those new standards and infrastructures and just been aware of LLMs and other a AI architectures.
It was probably something which we will be covering in the next edition of the Leadership Compass. And with that, I can only recommend you some additional research for reading on our website and thank you very much. Thank you.
