Hello, and welcome to another KuppingerCole webinar. My name is Alexei Balaganski, I'm the lead analyst at KuppingerCole here in Germany. And today I am joined by Isabellele Mauny, who is the co-founder and CTO at 42Crunch. Hello, Isabellele. Our topic, as I was just saying for today is why continuous API security is key to protecting your digital business. So today we are talking about all things API and API security, but before we begin, I have to spend a minute on some, the retirement and housekeeping stuff. First, let me remind you about a couple of upcoming KuppingerCole events, which will happen very soon. In fact, next week, we will have our next virtual event, which is online only. And this one will be focusing on securing a manufacturer in the industry 4.0, it's completely free to attend. So everyone is welcomed.
And on November 9th to 11th, we will have our next hybrid event. Meaning we will have people in the rain physically, along with some speakers and moderators from KuppingerCole present. And the rest of interested people could attend remotely. You will find more information about that event, cyber security fellowship summit on our website. And I just want to give you a hint that both me and Isabelle would be given our presentations at the event. And of course we will be talking about API security as well. So housekeeping, everyone is muted. Centrally is usual. You don't have to worry about it. We will be recording this webinar and they will make the video and the slide deck available for free download on our website. Every attendee will get an email with the link, how to download those files. It's usually we have a few, a nice session at the end, and everyone is welcome to submit their questions.
Using the GoToWebinar control panel. We have a special section called questions. You just type your questions in at the end of the webinar, I'll read them aloud and we'll discuss them together. I want agenda for today is a little bit unusual because we are not going to have two separate presentations. In fact, me and Isabelle will be talking intellectually over a single deck, discussing all the APS security challenges you have prepared for today. And we will kind of go back and forth talking of our slides and kind of expecting your questions. And again, you can submit them anytime. Maybe I won't read one, allow it when it's fitting in the discussion or it will have to wait till the last part of the webinar. And I think it would be fitting to start with the one basic question. What is an API anyway? Like why do we have to talk so much about ABI and security them after all justice, some obscure technical term, nobody cared about just maybe educate the go because on its own and application programming interface is just a set of rules, which is quite how two different pieces of software communicate with each other, nothing more, nothing else.
Oh, the one reason API school invented and they both invented like over 50 years ago is to ensure that people building complex software can make the lives a little bit easier. If you can see on this slide or kind of the timeline of API reflect really curious kind of evolution, because it all started with some wake technical ideas back in the 1960s. Actually API started to make a lot of sense as soon as computer networks appeared in the eighties or nineties. Because as soon as you have more than one computer, you have to devise a standardized way for different programs to talk to each other. And of course it was quickly picked up by enterprises because KPI's allowed to create a complex or service oriented architecture where multiple pieces of software will communicate or analyze messaging math or service boss. And it was happened. It would happen with help of product Pronto calls such as.
So for example, eczema about cloud came of course, API is what immediately the native part of any cloud. So is because at the cloud scale, you have to use some kind of automation to control those services. You will do that with an API and sooner or later, or the businesses have picked up on the idea that you can actually tell your sources, or even then when your products through an API and for many, did you still data itself has become a product for companies like Google or Facebook or any other large companies working in the FinTech industry. For example, they basically deal in information and API are logistics, which allow it on a huge scale. And back in 2017, a well-known journal is proclaimed 2017, the year of API economy. And then two years later as slightly less well known, let's do an important company called KuppingerCole has proclaimed the fear year of API security.
Basically we have started following this market quite a few years ago there, and we have published first market review or the landscape in 2015 back then there was exactly one company which claimed to be an API security vendor in our last edition, which was published this year in August 31. So the market is growing. The API security awareness is growing because there was a lot of nasty stuff happening in this area with data breaches and compliance violations and so on. So API security is a kind of a big deal now, and we have to talk about it today. And of course in this webinar, we will also try to predict what would happen with this industry in the future, because there is now an interesting development happening, which I would call an API singularity. There is more than one way. I believe that the market can continue developing and we have to talk about those alternatives.
But more importantly, I guess the question is like, why is API, what is it using? What is being used for? And on this slide, I have collected a few examples of kind of the humble beginnings of the API before the cloud era. But the majority were used to basically help developers program their software a little bit easier quicker, but later they were picked up by enterprises or kind of jump started the whole digital economy API economy. And right now they are primarily used to everywhere because they power mobile apps and services enable microservice, cloud native software architectures the other big bone for the internet of things. They are helping companies to collaborate on those partnerships. And as I mentioned earlier, for some, they even allow selling digital data F their new oil, if you build a new gold and what do we have today? And I think it's would agree with me that could have today.
We have a huge mess around API security. First of all, because Ericsson now comes with an API, many companies proclaim that they are basically, you know, API first in their development strategies and whole industry is now critically dependent on API is being available all the time and working properly, which is all those fintechs banks, retail organizations, healthcare automotive industry, basically a Tesla car is like a small scale data center on wheels. And that comes with hundreds of API APIs and API is, can be exploited to basically crush you during your 3.5 Tesla. And we can naturally see that there are texts on API. APIs are increasing. One company have reported a triple increase in a text on API recently while the other one, which I was just talking about yesterday in a very fine newsletter, the 42 crunch, publish it on the area on the topic of, I guess, security, only six companies reported.
They had never had any API security issues before, which is kind of boring, I would say. And I guess we have to think about how to, how are we going to deal with this tomorrow? Because we see that the API complexity is increasing. You have new types of IP APIs, UL, GRPC, totally new protocols for Thunderbirds, which are very different from the traditional quote, unquote, the restful API APIs. We all know and love. They are much more complicated. They are convinced in their own you security issues. And of course the, the shadow of compliance regulations like GDPR or PSD two or PCI DSS and other industry-specific regulations looming upon all API because violating both or regulations is becoming much more costly than ever. And of course you are all, you have to invest a lot of efforts and money and thinking into the proper API security strategy.
And without that, I have to kind of highlight, I think, which in about, we'll be talking in detail later, that's creating an API, managing an API in the end security API is not a point in time thing. It's not an event. It's not even a process. It's a life cycle because API evolve, if the eyes are not just products on their own, if you have to just means to enable business and business to deliver, and you useful product and with any other products, business ever-changing requirements. So will your API spiel evolve and the security threat upon your APS will evolve? Well, there was this a continuous circle, or you have to constantly change and improve, not just your API APIs themselves, but also your risk controls. And finally, we are going to the topic of, so what actually is API security? Sorry.
Many people would obviously believe that API security is just the API risks, which I've listed on the slide. The so-called API talk 10 risks. I worry about no organization, which compiles a lot of security research around API APIs and other areas like application security, for example, and they have identified, I believe it was back back in 2019. There's a list of the most critical technical threats and risks. An API can experience. My problem with this list is only one. This is way too technical. This is not where you thought thinking about this. This is why you and thinking about it because if you look closely and we don't have to go into details, but you have to understand that most of these threats are just consequences of bent design decisions. The reason why your API would eventually fail because of one of these threads actually kind of is hiding way, way back in the earliest stage when your API did not even exist, it was just being out about
Absolutely. And then that turned into what we see. A lot of our customers is they end up in the situation where they have to deal with this API top 10. Then they're realized that way, way back in the EPL life cycle, they've not looked at something and they have maybe not taken the right decision because they have not analyzed properly what the API is going to do or how it's going to be consumed. So it's just something to keep in mind. But design decision, I chose this picture here is like, I really like it in terms of like, how did you recover from this? Right? So yes, you have a functional maybe bath here, but you have also then is you're being really hurt when you get out of it and this, you want to fix this, you'll have to break it and redo the entire house probably entirely.
Right? So let's have a look maybe in the next slides and some of the decisions and what we see, what you have to do and how that links to this API top 10. Right? So first of all, as you all know, security is all about a risk, right? So before we do anything with API, APIs is like, what is the risk of exposing that API? And a risk can be influenced by many different things. It can be, is this an internal API? Is this something I'm going to expose only to a few partners? Was this something I'm going to expose to the entire world? Because that's my business model. That's not exciting was mentioning earlier. And which of those, you know, the risks of being comfortable with are higher as you open the scope of who is going to be allowed to consume the CPI, but also the data, you know, it's all about data.
API is, are all about exposing data and managing how that data is being shared with whoever you want to share it with. So what is that data? What is the data we're getting to expose? You know, what do we, you know, is it sensitive information that we're actually sharing? How sensitive is it? And then if it's very sensitive to me, if we look at industries like banking or insurance or healthcare, you know, probably it's not okay for them to just transport the data in clear. And I'm not only talking here about HTTPS because that's kind of a given all our APIs have to be over HTTPS. I'm talking about encrypting and in signing the actual data, the payload itself that we're transporting so that the data is not in the clear once that secure transport is actually over. So you don't have to that, you know, and based on that, okay, now I kind of have a threat model if you want of my API and who is going to use it.
So there's one use case here because I heard this from many customers I want to stress on, which is the, the danger of starting as, oh, this is just an API we're going to use for ourselves. And it's going to be used by one application, right to, oh, this is really cool. Now we're going to expose it to our partners to, oh, all partners love it. So now we're getting to expose it to everyone. Every time you make those changes, you're changing the rules, you're changing your risk. And therefore, as Alexa was saying earlier, this is again, not a point in time story, the design you have done when the conditions were X have to be reviewed. When the conditions are actually changing, she was, you have to evolve your threats and your risk, right? That's an important aspect of this now in terms of designing the API itself, right?
Of course we'll have to design Wu has access to this. So what is the authentication model? What is the authorization model one? You know, the top one issue and that list is about is I'm a physician problem is about, you know, Isabelle being able to access account 1, 2, 3, but that belongs to me. And I should not be able to access account four or five, six that belongs to Alexei here. So that is really a, a core authorization problem, which is really hard to fix once you finish the implementation again. So you have to think about this, like, what are the resources we are going to expose and how are we going to, you know, authorize access to those for the resources, the data itself, what are the operations again, how those administration operations are normal operations? How are we going to make sure that only administrators can access that part of the API, et cetera, et cetera, right?
And one huge, huge aspect of security for EPO is, is data. What is the data that we are transporting? What is the data that comes inbound? What is the data we're going to return? And then I see too often in with our prospects and customers that in general, the data definitions are very loose. They are very open, you know, in terms of what is the data that can be accepted in. And this is one of the top six problems in that list, or what is the data we're exposing out, which is going to be a one on top three problems as a lot of problems. If you look at API security, you will see a lot of problems related to returning way too much data that we should be because we trust and count on the client applications to actually just take in that amount of data.
We have returned, just take what they're interested to show to the, to the user. But if I'm going straight into the API and I'm not going through that client layer then, well, I'm actually seeing every piece of data that API is returning to me. So defining the data we want to expose and enforcing how we're going to expose that is also a critical aspect. And finally, we're the only journal. We don't think too much about this, but we will have to operate then that API, right. We'll have to decide on the rate. Limiting readily, we think is something you have to design again. I see too many people just say, oh, well, we'll put this later. Whenever we deploy this into API management solution, for example, and the ops guys will do it this well. No, because it has security implications that you have to design as well.
Logging monitoring. If we want to do any kind of forensics, you will have to have the data. Again, something very complicated to bolt on once all the code is written, right? And that also has some security implications. What data are we getting to log? Where are we going to poach it? So all of these are potential problems and vulnerabilities that again, see their roots into design. So there's one really clear message here is that if you really, really need to think, and that's, I guess what we're trying to help with is very much aligned with that. With that thinking is you're really, really have to make sure that security becomes part of your original thinking and design, as opposed to something you bolt on. Once all the code is actually Dawn and written. Right.
Right. And they find my , I guess the huge point here, that's a lot of money. It's actually not even kind of inherently related to API for themselves. For example, just mentioned, right. Limiting what would be the point of setting some arbitrary rate limits on an API, which actually just translates to calling a backend, which cannot keep up with the Trek limit. So you have to think about that, for example. So you have to collaborate with your backend team. If it's something to be realized on specific business logic, you have to incorporate that into your API strategy as well. Data you just mentioned, I mean, data usually leaves completely outside of the grasp of developers or API ops team. So to say, because like, so you have to collaborate with DBS and maybe even security people and compliance people who define all those policies where you can, if you cannot do API security in isolation, it has to reach out to a lot of different stakeholders and technologies and so on. And you have to start thinking about all this stuff way before you actually buy a quote unquote API security tool.
Yep, absolutely. Absolutely. And this is something that we, you know, we're going to start touching base on, on DevSecOps. What does that mean from an architect from a cultural point of view, but it, you know, I'm, I'm deeply convinced that you can not do proper security with all those different teams collaborating with each other. What we ha we, I think we lived in a world where all those, you know, dev and security and ops are like teams, which are like isolated pretty much from each other. And then basically we throw a whatever application over the fence and go ups and deploy it. Or we throw an API over the fence and goal security, look at it and tell me if it's okay or not, then give it back to me. Oh, by the way, you have only two days because this has to go out for tomorrow, right? There's no way we're going to be able to do proper security. If we continue to work this way, we really have to collaborate much better have tools that allow you to obviously collaborate so that we can really do this in again, iterative fashion. And we'll, we'll come back on that a little bit further on in the presentation.
So basically this is kind of the goal of my next slide is basically to show you that the real life, again, quote unquote, NPR risks are actually just about API APIs alone. You have to think very general terms. So yeah, we have to implement an API because we want to sell our digital product, or we want to collaborate with a partner or we want to whatever, solve a business problem, the question shouldn't be, how do we do this quickly? But safely, if you guys security kind of is the heartbeat, but it's not everything you have to think about. How do you even know how many, I guess you already have and how do you keep up? Because you probably already have way too many don't even know about. So can you even start thinking about properly security or like a digital interface to your sensitive data, if you don't even know which data you have, where, and which API is already connected to that data, how do you actually keep up with all the and risks and anomalies and anything that happens to your API in real time?
Can you, I mean, what does it make sense to turn your additional security operation center into an extension of your API security and have a human that reacts to every potential? And normally with regards to your API APIs, what if your API is, are called? I also like 5 billion times a week. Do you have to investigate each of those transactions separately? But if human probably not. You have to start a little bit earlier. How do you teach your developers to develop the backend code in a more secure manner or that even if, for whatever reason, the outer layer of your API security fails, there is one further layer inside which books, which with you Holt and maybe some power tools in place. Some other coding practices, whatever things controls that will prevent that from a full-scale breach and how we actually prepare anything breach. Because if it's already happened, you can have the best forensic investigation tools.
You can have a legal team on retainer. You like, you can train many times what to tell to a journalist, but wouldn't it be much better if you could just have prevented the breach from happening at all, how do you do it? How have you designed your system to be proactively resilient against breaches and not just quickly react to what happens and of course last, but unfortunately for many companies, not at all the least, how do you ensure that your compliance checklist is all Austrian boxes tick we can, at any time you can show an auditor that yes, you fulfill all the requirements of GDPR, PSD, two PCI DSS, any other regulation, and only when you have all these questions figured out, you can start thinking about what the top 10 and technicalities. So would you say, I guess that would be my biggest takeaway for anyone watching this, maybe not today, but let's get back to kind of security architecture
Indeed. And then, you know, taking on the points you just raised. So what, what we really see is, is, as I said, security is a journey, right? So it's not a point in time. It's a journey. It's something that we need to address from many different points and we need to make sure we can engage with all the different consistencies of the people, you know, the teams, which are involved from all the way from design to production type, right? And if we look at this from, you know, the high level view, we'll see, there's basically three main components that we need to really care about when we deal with security. Of course there is protection. That is something that we are going to put in, in the line of traffic, or that is going to look at all the information, validate the content that we're talking about is that data and receiving or returning the proper one I'm I, you know, are receiving something I can recognize as a threat, do this rate, limiting traffic draw thing that we were talking about.
So we need something there from a protection point of view in the line of traffic stopping in real time, the potential attacks that were under texts that we were receiving. That's one aspect. But the other aspect is again, is, is, is how do we be more proactive? And I'm coming back to this in a minute on finding those problems to start with like, ideally, you know, what we would like to do is we will have a runtime protection system in place and it will get everything go through, you know, and, and that will be fine because we don't have anything on there, vulnerabilities these at all. We're all good. Right? We don't have any problems as to how do we get there, how we do not introduce vulnerabilities to start with. And there's only one way, which is to start early and to start the design time and to start by finding early, Hey, my code has this problem or my data is not well-defined or my authentication is actually not working properly because if I'm sending an expired Dogan, then it works.
Or if I'm again, Alex, say trying to access Isabellele's data, it works. So there is only one way you'll be able to actually do this is if by doing automated and test the testing and analysis at design and development time of your API. So that all those potential problems that you might be introducing, you're going to detect them early, where it's easy and frankly, much less expensive to actually address, right. And the last part of all this is access control. So everything around, again, those sensitization with our position identities, this is a huge part of, of API APIs and making sure that we don't have any broken authentication with our physician is, is really a big part of the design again. And it kind of really connected to the testing part as well. Right? So, and all of that needs to be, you know, working in a continuous way.
So this is, again, not a view. There is something that we're doing nothing differently in the markets authority to crunch is looking at this problem in, in really, and then, or reasonable way that is traditionally security has been very siloed. So like the security guys do this, the developers do that. They each have their own tools and those tools are totally disconnected, right? So the, the, and, and that's, you know, again, our strong belief is if you want to do security properly, though, those three different steps, like the design, the development, the deployment, et cetera, and different tools you're using around the API life cycles need to be connected and need to be like, you know, everyone needs to speak the same language. So we're looking at that probably more in an Oriental way then, then than in the siloed way. And that's really what the platform is all about. So if I get into more details of that one, go to the next slide, Alex, say, go ahead, please.
We actually had the first question from our audience, and I think we can address it right now because it's kind of somewhat related to this whole idea of too much complexity insecurity and all those silos you mentioned just now isolated teams could have put it into different directions. You could have different priorities. These all are caused by this overwhelming complexity. When you have to juggle multiple tools and security stacks and controls, which are not connected to each other. And the question was actually, what about putting our API into containers like them in containerized architectures? Would it help make them more secure? Yes. And no, of course it would help or on one level of abstraction. But if you just kind of introduce another layer of this technology stack, if you bring in Kubernetes, for example, or you are bringing in a lot of third party API APIs, which would have to secure as well, and you have to have people actually could have been experts in Kubernetes to configure it properly. And so basically you always have to balance this. You always have to balance or could have Haven, I don't know, 50, 6100, 200, maybe like perfect, best of breed, highly specialized tools, you know, toolbox versus a unified, as you said, horizontal approach where you have way fewer tools, but those tools kind of work in the court. They speak the same language. They understand the same policies and they apply to the whole life cycle of an API, for example, although this applies just as well to any area of cybersecurity. Okay. Let's move on to your next slide.
Absolutely. Absolutely. And, and, you know, I guess, you know, w one of the things that in the API world we can actually do is we have this ability to really thanks to the technology, even some technologies to actually take a proactive, you know, positive aspect of approach into security. Well, I mean, by that, so proactive, you know, the opposition to that is reactive. So what we see a lot of our customers doing so far, and it's been traditional security again, has been the developers develop an application, right? They do functional testing on top of that. And then that will just, again, pass this on to the next team. That might be the AppSec team, which is going to test that. And, and, or they don't have the time. I had plenty of our customers telling me, I know this is no good Isabelle, but I have no choice because back to conflicting, I would say requirements and priorities of the different teams.
It's like, okay guys, you know, put this in production. It has to go out because we promised the business, this application will go out today. And once it's in production, we'll see if we can put something in place or if we can throw something at it and, you know, see if hopefully this is going to make sure that nobody can get through. Although we know that this API has some problems, so we're really in a reactive fashion, as opposed to a proactive, you know, approach in a proactive approach, you know, we need to get to, and this is an evolution again, you know, this, this is a journey again, it's the journey of being able to test early, find problems early, as I was saying, and this is where we're starting to talk about automation and DevSecOps and security as code. So taking approaches similar to, you know, you describe your security in a way that is something that can be automated.
It can be analyzed. It can be enriched. It can be versioned that can be tracked so that everyone knows, okay, this is the way to CPI is actually secured. Security can say, you know, developers, you've developed an API call. Like our requirements within our company is every single API must be secured with, on the throw some off the Grande types keywords in here, you know, with auth with authorization code green type and pixie, that's it, that's the way it needs to be. So here there's no place for API keys or basic auth. We don't do that. How do we ensure that, like, if I have 1000 API APIs, how do I ensure across my entire company that everyone has been following the roles? How do I not discover that when that API is ready to go out? Right. Well, the only way is to take a proactive approach by which I can, whenever an API is being created, validate that actually it's properly, you know, set up and it's actually doing, and following the compliance rules, that's a proactive approach.
The positive aspect of it is really about versus negative, right? That's the other side of the story. Traditionally security has been about a negative model. So let me explain that maybe with the next slide. I think we have a little picture that will allow me to explain what that means, right? So traditional tools have been taking an approach and I'm talking like traditional web application firewalls, for example, an approach whereby they look at the whole, the traffic coming their way and they read it all know about the, what is hitting, right? But see a bunch of traffic and strings and data coming up. They have no idea what that data should be. You know, traditionally we are a no way to describe that. So that means the only, you know, solution that we had that would scale would be to create massive rules of, of attack patterns of some sort.
And those rules can be managed manually, which is like the worst. Some next generation things have been, you know, creating those rules and being a bit smarter at looking at those rules and, and, and getting them to evolve. But then the end, it's always about the things you don't want. That's a negative model. I'm looking in the traffic for the things I know could be potential problems. A positive model is the other way around, which is really based on real closing the door on everyone. But the things that we know are the things we actually expecting, right? So we have the ability to describe in, in, in an open API contract, Hey, this is my contract. It can be based on open API. There's more specs coming our way. Now it can be enriched. We see a lot of customers and reaching their own contracts.
But the key point is I have a way of describing, Hey, this is what my API does. This is the data transports. This is all the operations that's would support anything else that comes my way. I don't want to hear about it. Right? And it should be stopped because that's not what I'm expecting. So that's a positive security model, which is much more powerful in the sense that you don't have to keep up with threats. The big problem of negative is as new threats come up, you have to update those rules to take into account those new threats, right? So a positive model allows you to keep up with what you know, which is what are my API is, and whether they do, as opposed to the things that you don't know, which are an evolving world of new threats and attacks that someone needs to work on for you, or manage rules manually for you automatically, if this is coming from your vendor, whatever, but it needs to be all, you know, be kept up and why a new threat comes up until you have in your role that can detect it.
You're basically not protected against that thing, right? So the, the contract, what he delivers is what we call context. It gives information and context for an engine to take a decision on whether something is valid as traffic or not. And I'm just taking 30 seconds here also to say that it is also very important to look at the responses. You know, the top three on that API, top 10, that we looked at before is about data leakage and in exception linkage. So this is about the data you return through your API. Most of the security solutions today are very much focused on inputs, validation, not so much on the outputs. However, you have top three here where main problem is, is output. So you really have to make sure whichever system you put in place is capable of actually looking at the responses and then forcing that you are not returning to the outside world. Anything you should actually be not to return.
I guess the biggest problem here that again, the market can definitely offer you a lot of interesting tools, which focus exactly on the leak prevention laws from starting from north old school DLP tools to modern AI powered fancy tools. The problem is those are sold to you from a different vendor, probably even to a different team within your company. And they are not in any way connected to your API infrastructure. So again, you have this unnecessary increasing complexity, probably overlapping capabilities, which do not currently kind of correlate to each other. There is no internal communication. There is no internal cross-checking, if you will, although security events, we hear you can generate a lot of findings, but you will have to go through each finding individually. And in the lives of those enormous, have a team of humans making a lot of decisions you just scale at all, especially for a while. You have to deal with millions of billions of transactions.
Okay? So sometime as I mentioned, we have published another edition of our initial compost on the pain management and security. And actually I already did a separate webinar explaining all our finance. I just wanted to bring this one flight back for a second to just demonstrate that when you're looking for a security tool, you have to look for more than one thing from other than one capability, which kind of are the first site might not even look like they are interrelated. So like, why would you have to look for developer tools in a security solution? Or why do we have to combine security analytics? The purely reactive thing we just discussed, like your security operation center staff with API life cycle management, the practice, but unfortunately, or API security is complex. So either you have to deal with a standalone this disparate tools for each of these capabilities, or you have to look for a third, which cannot list combine some of those two.
And absolutely it doesn't have to CA to be able to do everything. It doesn't have to be a jack-of-all-trades, but the more capabilities such as solution can incorporate the more of a cross-pollination you have from your security findings, if you will, the more efficient it will be at filtering out the noise, reducing the human involvement and allowing you to automate your API security as much as possible, and just kind of quickly mentioned or hiding. So, as you can see, we had quite a few companies in our mind rating, and we had quite a few interesting developments among our leaders, but you have a huge companies like Google and Broadcom and red hat, and you have quite smaller companies like 40 to crunch the fair and pretty well among the readers as well. Why specifically, because of those quite unique capabilities, the predictive capabilities, which nevertheless can be efficiently integrated with the rest of the Ika security, if you will. And the game kind of to highlight that, yes, this solution cannot deliver you profit ratings on Emery excess. We have a Analyst, but for many use cases, this is exactly what you have to look for, not the Jack of all trades.
And I guess I could probably give the stage back to you to explain how
Absolutely so, so I would say you can see what you're seeing on screen right now is, is, is really what I call the veer truce loop of . But what we, back to where we were seeing earlier, we look at security as being a journey across the entire API lifecycle, where you cannot have disconnected information. You need to have a connection in a streamline process along the different capabilities of your API security platform. So our, our goal and our vision is, is like this, right? I'm a developer, the developers, or the re the people within your companies that know what API is, are doing. They know the data, they know what the operations are. Hopefully we followed what we said at the beginning. They have an idea of, of the, you know, the security threat, the risks, et cetera, and based on those risks, and based on the definition of DPI is they have a good idea of what it is that are the rules and the definition of the contract of that.
What is my API? How is it secure? What does it do to have a good idea of that? Now, now we have to put it to the test. So first thing is, I'm a developer, I'm just creating the contract. I'm pushing it into some kind of CACD automation and some automation is happening. And this is a really a key thing. Most of the companies that we're talking to have hundreds of API. So while you may have been capable of manually a, you know, looking at the code and see things, or you have problems in there, be looking at their contracts and see an API open API files and see if there is any problems in there, see medically come verifying. And then that upstate for a second, that the proper policies were in place. You'll be able to do this for maybe 4, 3, 5 tannic guys, maximum beyond that.
It becomes unmanageable, especially because it's not a one-time thing. So it's like I'm creating one API and never changed it again. Maybe it's going to be redeployed every week, every week you have to go and do it the same or every day you have to go and redo the same testing again. So the idea is we started in contract automatically. We'll go and analyze, going to tell you, Hey, your security is using API keys, or it's using that. This is a potential problems with that. You're a Datacom. Your data is to lose, right? You don't have any constraints around it. You have the find only one type of response. We see this all the time. You have only a response code, 200. So your API is always work. That's probably not right. You've only have times where, you know, either with our position doesn't work or the data is wrong, you probably hold all the type of response code.
So we're going to help you, you know, enrich and constraint the contract. And once you have that defined, it can do a lot of things automatically. You can do testing automatically because now, you know, the contract does, you can enforce and make sure your API actually conforms the implementation, confirms the contract. And we can also do a lot of automated testing that I was talking about before, because we know how the API should be behaving. So we will send you some bad data. I will send you some bad formats and some bad content types and some bad verbs, and all of these should be handled nicely by your API, according to the contract again. So all of that we can discover automatically. That's how we find that some customers, you know, problems and mess assignment from a data leakage from, with broken authentication, all of these are going to pop up at design and development time, right?
Automatically every time you change the API, we do this again. The next thing we'll be doing is also we can, because we're using the security as code approach, right? We can do automation, automation of policies, for example, this is a big problem. How do I, and I'm sick version and fours that again, off with Pixi back to my previous example is required across the board of that. My Jason we're talking such have such a trust structure or whatever, right? Those policies, you want them to be easily, you know, you can insert them automatically into your API APIs. You can enforce that. They're there. You can make sure that they're deployed again, and you want to do this automatically. All of that in your CICT all fed from the same contract definition and what we're talking about, and that we want to take those policies and we want to enforce them now, right.
You know, or runtime protection piece of we're talking about later. So you see there is this like continuity in that flow that we are starting from what the developers are actually producing all the way to testing and to the employment. So every time something changes into deployment, we'll be able to catch it up early. We'll be able to automatically insert our policies, automatically enforce our policies. And we can do this all day long across thousands of API APIs. So that's the automation and scale that we're bringing into the picture right? Tomorrow. You want to add a new policy across the board, not a problem. You go to your CICT, you inject a new policy in there. Boom, every API in your system is now enforcing that that's really our value proposition and where we want to be, so that we give you that proactivity, that continuity and that automation across all your KPIs.
Right. And I guess it's probably was to kind of emphasize once again, that the earlier you do it, the more efficient your developers will be in all aspects of security, but overall productivity as well. Because as compared to, for example, the traditional source code analysis, which kind of does the same thing. But once that later in the life cycle, probably only that one X of step, but a source code analysis tool can identify. I would say hundreds of similar mistakes development has made while are doing it. A design time would have prevented 99 or those, because you only have to understand once the developer does something wrong and then use whatever automation or just kind of some decision support, maybe like a nice logging or IDE. And Hey, it looks like you're doing something wrong. Like, you know, the Microsoft's Clippy, but a security question, looking, just try not to do it again. And this would kind of reduce the number of the actual mistakes in the actual code by 99% and kind of save a huge amount of problems at the later stages.
Indeed. And that's a key points you're mentioning here is one of the things that you said at the beginning that we were doing a four digital crunch. It's this API security that IO community is really a community effort on education. Because truly again, back to your comment earlier, or one of the questions, if your security is, is a complex thing, there's a lot of layers as well. So it's, there's the API itself. It's also the libraries I'm using and the containers behind it. And you know, there's a lot of things that I have to look at and, and, and automate, and education is very critical. So, so when you see the reports that we were producing, one of the key thing we've been investing is making sure we have this SQL pedia that will, you know, teach and tell people, Hey, you've done this and we see that potential problem.
Then you explain to you what the problem comes from. Let me explain to you what the potential, you know, vulnerabilities can, can be the outcome of this. And let me explain to you how to fix it. And what we see at our customers happening is while the original API is that people are looking at might have a very low score or writing, basically, because when we do this audit and this analysis, we give a score, maybe they start with five, 10 out of 100 over time, that score becomes 40, 50, 70, because people have learned and they'll that's right. You know, if I do this wrong, I'm going to do this audit again. And it's going to tell me that's right now. I know. And that's, if I do this as a potential problem, right. So education is key. It needs to be continuous. It's, it's, it's a very important part of making sure, again, we're not introducing those vulnerabilities to start with.
Okay, great. Moving on.
Yes. And next great. A great example of that with, with one of our customers, we've been doing this really at massive scale for the past nine months now, and almost a year while the time is fine. So tons of API APIs, 1500 plus about 2000 developers there. So they've done exactly what I showed in that picture earlier. So this is completely part of their development life cycle. Now they're using our ID plugins to use those auditing and scanning tools. They're they have embedded our different tools into their CICD pipeline. So now, you know, it's just the way it is. You just push a new piece of code, push a new API automatically it's getting analyzed, et cetera, that, and they're seeing, they've seen something, which is really interesting. And we will talk about that, that the, as a cyber security summits, which is the quality, so we're talking about security, so security is important, right? But they've also seen the quality of their code actually being much better. Thanks to what we're reporting. So security is obviously better, but the quality is also better. So the massive use the use of, of the system and definitely the epitome of implementing shifts left and, and design time strategy with our platform.
Okay, great. So I guess the last thing to discuss in our want to be what's going on to happen next year, or in a couple of years within the area of API security. And as I mentioned, there are, some are kind of ongoing challenge. If we can observe today, average would definitely have a massive impact on the future of the market. The question of how do we know how the market will react? What would happen? I guess one of the challenges I listed here are obviously first of all, API APIs themselves are becoming much more complex. All those new types of standards and architectures continue to appear almost daily, simply because as I mentioned, businesses have new demands. They want more and more scalability, sophistication, some entirely new business models in new industries. And all those new use cases produce new technologies, which API management may based security platforms have to quickly support.
And sometimes similarly, small things like, okay, you already have everything in place for right. The rest API. We just have to add support for graph QL. For example, it's just the same HDP product protocol. It's like the same text-based protocol to analyze Schuler. It should be easy, right? Unfortunately kind of the logic behind that is completely different. And for example, you cannot apply a and rate limiting to a because they are not created equal. One curate can put your entire backend to its knees because it's, it will be too complicated. So you would have to add some much more sophisticated analysis, your critical security for one so on and so forth. And of course, a basic monitoring and reactive response just doesn't work anymore because they cannot scale to thousands of API endpoints and billions of transactions in the end, complexity, skyrockets costs are mounting.
I've even read some article proclaiming the upcoming end of the API economy because just to publish a single API becomes prohibitively costly. And when it companies, it's all the traditional tools and you have to completely rethink and redesign your API management and security infrastructures and architectures and 12 concepts, if you want to reduce those costs. So with all those complications and sophistication or whatever, additional compliance pressures on what would happen to the API security tools, would it even make sense to invest in any security tool today? If tomorrow it probably won't work at all or have to be adapted to completely different requirements. Well, I believe you have to do it today. Actually, you should have done it yesterday, ideally, but since you have not, you have to do it today, but you have to do it the right way you have to. Or we just discussed with the whole webinars that you have to make API security, not an, add-on not a bolt on to your existing infrastructure.
You have to, or we would into your whole application and API design lifecycle, or you have to secure the entire life cycle. So every time you hear someone talking about shifting left, it's great. If it's awesome adjust, you can left alone. Won't work. You have to shift in all directions at the same time. And you have just like Ellis and that behind the mural tail, you have to run twice as fast to get somewhere. And you have to invest into a solutions which are intelligent and automated and proactive. Because again, you cannot just, oh, your security analyst to do a forensic investigation and analysis and decision making for each API related incident because sooner or later you will have thousands Bailey, then you will have thousands hourly. And maybe even millions of those incidents we have to automate because no, no human and no company can afford hiring so many human analysts to keep up with pretty moderate requirements, API of API security, where you have to leave people involved in policy making, but not in decision-making.
And finally, unfortunately you probably still cannot buy a complete API security architecture from a single vendor, and this won't ever happen. In spite of the ongoing trend of larger windows, acquiring smaller companies do notify for integrating those tools. You cannot integrate fast enough to adapt all those ever-changing requirements. So you have to design your own architecture. You have to make it flexible and kind of ready for the future changes, but you have to start somewhere and the quote, unquote, data centric security, which actually applies to API security as local, you have to focus on protecting the data instead of protecting infrastructure is probably one of the right ways to do it. And this is exactly what we discussed today, basically. Right? And with that, we have a few minutes left. What questions? And do you have any, I believe you already have a couple of questions from the audience. Let me just read them aloud. So how exactly are sets authentic application security testing tools are different from what 42 crunch offers that solution.
So the, the, the key difference really is that we're not looking at the code. We're really focusing on the interface of the contract, which makes our solution to, to the agnostic, to, you know, you can write her replies and whichever language you want. It's, it's, it's something that I would see as complimentary to system desk. You can, you know, do analysis, dynamic analysis, I think, and a is of your code. We have customers doing that all the time, using solutions like, you know, solar cube or things like this, or do Linton to do complexity, to do all kinds of, you know, analysis. What we have seen though is, is really SAS and desk tool. Well, sets in particular are really not API specific. Like they see code and normal. This is an API, I've got the, like the context again, and we're back to the same story.
So that we'll find some maybe obvious stuff related to the complexity, you know, to, to some specific, you know, maybe injections and stuff like this, that the usual things. But I will not look at like the data models and stuff like that because that's simply not something that there are used to do. So in that sense, keep using them for, by all means, if you have them, but on our side, we're a solution which is very much API specific that looks at the contract, and that will test the contract in, you know, against your implementation, giving you a very fine grain answer. Very, I would say precise report and also very fast, which makes it, you can, in a couple of seconds will get to report.
And I think you mentioned a bit earlier kind of, if you thought with such a tool with contract validation, before you write any code, you want to save a lot of kind of code reviews and scans later because you won't have to identify hundreds, similar problems in the code, which actually could have caused by the same inherent vulnerability in the contract. So you have to start even earlier, like you shift left even further than
API first approach. That's definitely something you'll be able to do. You'll be able to get some results before you even write any code.
Great. Okay. Now we have one minute left for one last question. How big a footprint does your solution have? So how much overhead to buildings with these?
I guess this is in the, in the protection part, it's just a few milliseconds, really a very small engine, extremely fast, only 10 megs in size. Something you can deploy it across your architecture. And as I said, one thing back to audit and scan like the testing part, but also customers attending us is that your stuff is fast. You know, so it takes only a couple seconds. It doesn't take half an hour or a day to analyze my stuff. So I can really put it into the CACD pipeline and live it there for every single push. It works many scales at that level.
So can you serve 1500 API APIs with a single deployment or do you have to build out or distributed architecture for that?
Then we adapt to whatever the customer has. So if the customer has, has something like a service mesh and, and something like that, then we will just protect you the show, the APIs individually, most likely. And if somebody has more traditional architecture, you have gateways and more centralized gateways, and we will sit in front of those. And then we will scale up to, you know, probably three, 4,000 transactions per second in a single environment.
Okay, great. And with that, we have actually reached the top of the hour. So thank you very much, Isabellele, thank you very much for all the attendees watching with life or listening to our recording later, looking forward to seeing some of you in Berlin, on in person or virtually, because we have a lot of interesting stuff plant in API security and other cybersecurity areas. And I guess have a nice day. Thank you
Everyone going to take care. Bye.
