Hello everyone. Yeah, I'm from F five. I dunno if you know us as a company already, but we are doing applications and application security than more than 20, 20, 27 years now. And today I wanna use this, this opportunity to tell, tell you something about API security and why is this so important and what's the difference compared to application security itself, just in, in relation to this topic for this conference, cyber evolution.
I, I just wanna give an example why, why it's difficult or maybe it's different to have the right approach for air for API security. The application world itself has changed, has evolved over the last, I think it's almost 10 years ago. And what I mean by that is that I think it was 2013 where everyone started to, to think about move applications or move workloads into the cloud, into one cloud for example.
That's at least that what was, what our customers are starting to, to think about in, in 20 20 13.
Still just move an application on workload to one cloud is easy, sounds like easy, but it's one way, one access. It's easy to protect of course, or maybe can be easy to protect. But in reality, things never happened as expected.
And today, and you should know this already, we don't have this one cloud where all the applications are moved or where the workloads are moved. It's, there is a, there's a, a, a name for it. It's called multi-cloud because our customers, or at least almost every customers have not just one cloud, not just one destination. Wherever applications are located and where workloads are, are deployed in reality, we have AWS all the public cloud vendors, we have private cloud vendor. Each customer or every customer should have its own private cloud environment.
For example, we still have the, the data centers where all the applications still exist or even maybe exist for the next 10 years. And we have new things like Edge for example, where the application is as close to the, to the, the end customer or can be placed close to the customer. And as you can see, it's not just one destination, it's not just one access to the application itself because all those different locations needs to be connected. We have a connection, we have a communication east, west or north, south in all directions.
And this makes it at least a bit more complex and a bit more difficult to deploy or to to place the right security functions in place.
So with this new world, with this distributed world, we have still our applications, which can be located still in the existing data center or just move to, to one of, of, of the public cloud environments. That's easy.
But still, it's not, not the end of our journey because as everyone knows, we already have some, some kind of container or virtualized environments. That means we have, even the application itself has changed or evolved over time. So now we have no longer this, this big application which is in place in one location. We have small parts of the application or also called as a microservice or microservices or yeah, small part of duplication itself. And there is communication for all of those between all of those.
And to make it a bit more complex, you can even deploy containers in different, different locations. And there's one thing, this is the topic for today, which make this why it enables customers to have such distributed environment.
And this is a new way, a new protocol sometimes to, to communicate, to exchange data between all those microservices and application parts in different locations. This is called application coming interface, or in short it's an API and those APIs are used to exchange data.
And we just heard in the example before that APIs can be used or misused to get access to data, which shouldn't be accessible from, from outside to everyone, for example. But the important thing is, and this is something you can can see from by this picture, it is a distributed environment. It's not easy to protect all those microservices, all those containers or locations because if you are using the, the specific solutions from each, let's say public cloud for example, they are different.
It's not easy to understand or to provide consistent security policies, especially for API security and all those, all those different environments. But still applications, microservices, APIs should be accessible from for, for everyone, at least for the clients, for the internal, for the employees, and of course for the business partners as well. So you and you needs to have multiple access options for those microservices.
And sometimes even you have communications or most times you have communications where the microservice communicates to a different microservice without any client interaction for example.
But this is something not just you or your clients or your customers are aware of, but also the, the, the bad guys in the world and they have now at least some more places, some more angles where they can, can try to attack or can gain access to applications. This is the one thing why API security, especially API security.
I mean, I know there is more, more security needed to protect your applications in all those locations, but still the API is available and needs to be protected. But let's have a deeper look into APIs. We had just heard about that APIs are accessible and there was a picture where you can, could, could just use this, this source code for this API call and can just manipulate by changing a number or whatever and get access to, to data. You shouldn't, you shouldn't have to. Why is this? APIs are available by design.
They should be access by, by any client, by business partner I just showed you on the example before.
And of course to understand how to use those APIs, there needs to be documented, which makes it easier for a, for an attacker to understand where is maybe an a possible attack vector.
Where, where can I start to to to start my, my search or where can I try to get access to data which shouldn't be available for me and, and if I use this application in the right way. And of course, and again, just the example before APIs because of the design and then the idea behind, they can provide access to sensitive data as well. That's the design, that's the idea for for, for using APIs and exchanging data to provide such a Porwal. You could see in the, in the, in the, in the presentation before.
So this presentation was built, I think it maybe it was designed by different microservices and altogether WebEx were displayed in one, in one Porwal, for example.
But the communication between is used or is is done by, by using APIs. Alright. Today we have around 200 million APIs already. I just showed you the picture where you could see how distributed the application world is today. And right now we have already lots of places where it needs to apply or needs, needs to implement some kind of application security or API security functions to protect your application at the right level.
In the next couple of years, we expect this to grow up to two, almost 2 billion APIs globally. And you can, I think it's, it's, it's clear to understand that this makes this situation even more challenging for, for the, for the security guys to put to provide the right API protection I'm doing in time. Okay. This is just one, one big challenge.
The, the huge number of, of APIs makes it difficult to keep, keep the pace or keep the right security solution in place, especially for APIs.
It's any application security guy in the room. Anyone aware of how to implement application security policies for an application? It's difficult because everything is automated, especially in, in an API world. And that means usually customers have more developers than security guides to put, which are responsible to protect your application.
The pipe, the continuous integration, continuous development pipe is built for speed, not for security. It is hard for a security guy to keep pace, to be, to provide always the right security solution to protect your application. And that means API security today needs some functions to discover changes in the application in the API it, it needs some kind of of inventory to see, to display what is in, in my API, what is in use, what is maybe not in use, but still present. For example, any rogue APIs.
Is there something new, something different, something we, we, the security guy is, is maybe not aware of API security needs to provide such data to, to help protect it at the right level.
For example, just a quick look, what kind of APIs are available? It just depends on, on the excess level. If it is designed for internal use or for external use. I just want to want to go a bit more deeper because it's, it's not that easy to to just say it's, it's an application.
Just, just provide or apply an application or WAF policy and that's easy. It is not because API security requires a specific knowledge or a solution which is able to understand the protocol, which is in use. For example, just to give you one example here, everyone knows restful APIs. Maybe restful APIs is, is a common common API but isn't used since, since since years now it's, it's a kind of easy because it's a structured API, there is a clear structure of available endpoints, how you can access the endpoint, what kind of data you can get from them.
It's everything is, is it's clear and you have to use a specific method to get your data with from, from this API and so on. It is different if you're using for example, GraphQL. There is not just one end, not not a list of of of defined endpoints. It's just one endpoint. And you can use a query language to, to craft and to build your specific query to get your data.
It's, it's, it's a different approach and it is difficult for and the security guy to protect those application because there is no clear structure. You have to wait what the client is asking for and then you have to pass and to validate if this request is is a good or a bad one. And this goes on and, and it really depends on the solution which is in place and that means API security or to protect an application.
And, and, and these days, today you needs to have a specific approach, not just application but security. You need to have something specific for applica, for APIs, which is usually called API security, what is API security. In most cases it is, it overlaps with application security. But to simplify it, application security is used to protect your application against vulnerabilities like log four J for example. Everyone should be aware of this.
And any, any attempts to, to bypass the application logic to, to get data or get access to data, which shouldn't be available. API security is more focusing on the communica communication between different microservices. It's really going down to the protocol and not just the application logic and just one, one thing, which which I I think is, is really important without API security in, in these days, there's no a hundred percent or no way to protect your application at the right level because you are missing a very important part of it.
So just move on in in, in regard of time.
AAPI security needs to be automated. Of course, I just explained the example with the, with the pipe. So we need to have a solution which can be automated, which can be integrated in existing automation tool chains for example. But still it needs to have needs to provide some data about what is happening. Is it still the case? Is it still my, my API is is still looking like, like it should be because there is no change, no, no new endpoint or whatever.
If not, just explain me, just show me what happens if there anything new, anything unprotected or unusual or misbehavior from the clients, from the user, which could be or could, could point to a malicious activity should be available by the applica API security. And of course to protect it, not just say there is something wrong, but provide also a way to protect it in real time.
That's, that's very important here. Just have a deeper look to it and force what is known. So if you know a hyper restful API and know my endpoints and know my method and know my parameters, it, it's, it's kind of easy to protect as long as I could understand the protocol, which is used XML or whatever.
Jason, on the other hand, we should provide details or insights about any new, any rogue, any unmaintained API for example. And of course we should have a deeper look into the request itself, but also in the response what is delivered to the client. So it it's a, it's a full approach and the APIC security solution should be able to provide details and to protect your APIs in that, in that way. There's also one, one challenge, which is I just mentioned.
It is easy for, for a security guide to provide a security policy for an application, especially if the application guys are not informing those and the guys and say, look, we have a new version, please adjust your a WAF policy or application security policy.
Same is valid, is valid for, for API security. It can happen that, and this in the first picture, APIs rather and running in a certain version, API security is configured, everything is fine. They just deploy a new version of the API without informing the security guys, which is depending on the application can happen quite often.
Some applications have thousands of changes per day. So it's even harder to provide your application security policy at the same speed. But the API security solution should be able to detect there is something new and something different and provide at least some details so that, that the security guys can, can adjust their security policy either automatically or by, by reviewing it together with the application guys for example. But just make make them aware that something has changed without looking into locks three days or weeks after just in real time as soon as this difference occurs.
And of course this is a never, never ending or it's a loop. So because as soon as you have adjusted your security enforcement, they will deploy a new version and this, this process has to start again. So what is what we as a five can offer for API security? I still have three minutes, I make it more quick. So we have exactly this API discovery fee functionality and developed to provide those insights and to make it easy for, for our customers to understand what kind of APIs are in use and what are these changes for those APIs, how are, how are they used?
We also have a, a bot defense solution in place, which is a bit misleading because it's, it's not just blocking bots, it is also identifying unwanted automation. So any kind of browser automation or or selenium browser, whatever could be used can be detected and can be blocked if it is not, not, yeah, not useful or not wanted in the application itself.
And of course some, some details about the, the usage of the API, is it still my, my my or other my users which I access and the API or not. Is there something malicious be a spike in the, in the traffic unusual traffic pattern?
Whatever could happen should be visible in the solution itself. And just to give you a idea how it looks like, so this is something you can just, just enable API security define the ingress as where the clients can connect your application and define the egress where your application is located. Doesn't matter in which location could be public, cloud, private cloud, private data center, co-location doesn't matter for us.
We can securely connect all those locations without creating new effort for you by, by connecting all those locations and with this simply simplified access, we have a one one access point where you can, can deploy security functionalities and of course we can provide in insights on data informations about what kind of APIs are used.
And with those overview, we would easily see if there is everything fine or is maybe some, just, just one new endpoint in your API and you can do something about it. Same is for, for the behavior itself. How are they accessed?
I just explained before, is it still this as as it is expected or is it something unusual and you need to have a deeper look into it. For example, same is for authentication because it is, I just skipped maybe in the point before, but zero trust or the authorization provide access with privilege. Lease privileges is very important for, for providing API security as well.
Okay, so this is something maybe you wanna know if there is some attempt to access to API without authentication. And same is for, for getting insights about what kind of data are ex exchanged, for example.
And one, one last step, I have 20 seconds.
You can easily import API definitions to make it easy to configure, although your, your APIs. But keep in mind if you don't have those, we can just learn what happens on your API and provide you insights about this. And with this, it's my last slide, so almost in time get ready for lunch.
We have a solution in place which is perfectly designed for providing API security and connect all those distributed locations and make it easy and con, make it, give you a chance to provide consistent API security policies and of course application security policies to protect your APIs. With that, I'm done. Thank you.
