So yes, welcome everyone. My name is Julian. I'm sales engineer here at Imperva. I'm a kind of subject matter expert for the API security side of things. And I would like to share a bit best practices, which I saw from the field. As I'm a sales engineer, I in touch with the customers. I'm working in the project and see, seeing things firsthand. And I would like to share these impressions and give best practices where we have a lot of success with and why we are talking about API in general, because they are everywhere, right? So APIs are on the rise. We have APIs, a lot of organization exposing more and more APIs. APIs are upcoming because we see a shift from the monolithic application to the microservices of application. These microservices also communicating to each other. We also have APIs on mobile devices. We have them as a single page at single pages.
We also have them in IOT devices, machines to machines are communicating on a high cadence. And what we see at Imperva. So we come from the, from the application security. We also have big experience in data security. And what we see across our in store base is interesting number. It's 70% of the rep requests are API requests. And this is quite impressive and it's getting even more impressive if we have an increasing amount of API cards. We are also seeing some challenges from the team, from the security teams, from the dev teams, from the DevOps teams, which we have to, to, to cover. One of the challenges we see is that the, the, the exposure of APIs are increasing here we have to be a bit careful. We have three levers of exposure, right? We have exposure of APIs to the internet. We have exposure, let's say, of private APIs, which are going outside of the environment, but going to partner sources or, or, or customers.
And we also have internal APIs, right? As I mentioned, we see a shift from monolithic application to microservices to Kubernetes. We have Ingrid controller, we have load. So we need a extra layer of implementation options, right? So it's necessary to be able to protect your assets in front of your environment. We have some cases, compliant reasons, regional compliance regions that we have to be on, on premise, customer ask. They would like to have it. Air gap. These are all challenges the teams has to overcome. And one of the biggest is here we see 50% of our breaches are at the vector of APIs, which is a part of applications itself. And a scary thing is also the 50% of enterprise APIs are not managed. Managed could also mean that the security teams are not aware of these APIs. They are shadow APIs.
And you need to and at transparency on this blind spot, right? What I see when I'm, when we are going to the projects and we are did after the kickoff meeting, and I have the, the, the conversation with the dev teams. It's most coming. Maybe we have some technicians here who also say or agree with me that I saw api. The, the manager of the team said, No, we are, we are quite good. Every API is on under slash app slash API slash we run. And that's it, Especially in Germany. We are very trustworthy in our environment. But the truth is from the death side of things, technician teams, developer, they try to, sometimes they are under pressure in order to expose new features, new APIs and building new stuff, right? They have to meet timelines. So they did some testings. And then you have app slash API slash we one dev app API slash def, 1, 2, 3, test, 1, 2, 3, things like that.
And you have to be aware of your assets. It's a similarity to, to my colleague who was speaking before my presentation, you have to be aware of the things, otherwise you cannot protect them. And the issue with API is you have to be aware of them, of the APIs, it's safe. You have to be an inventory, but the inventory has to be dynamic, so dynamic as possible because APIs are changing even in between revisions. This is also something you need to cover and to need to be aware of. So this slide is talking about things we see or how we categorize application security threats. I believe all of you are aware of the first three of them. You can, you can protect these, let's say this is the similarity between over top 10, over API top 10, over automated top 10, right? We have an overlay in regards to authentication, service abuse, malicious. So you can work with request limiting details protection to some certain extent. But when we go to, to API security, then we have a text on the logical level, right? We are talking about broken object level authorization, things like that. So these things are quite hard to uncover, to detect, to remediate. And at the end of the day, to block.
So, and this is why we have a transition, let's say from the web application firewall or application security to API security because the tech vector is rising to the, to this part of the, of the applications. And as I mentioned, when we focusing on OVAs API top 10, you can with an applicative security device or a bunch of different devices or preferable with a single stack solution, you can build a layered security approach, right? You can, you can do the ddo protection or the abuse of the API with things you might have, or you might want to consolidate with one single stack solution. Another important point here is the point API access management gateway. A lot of customers confusing them with API security devices, right? We see a lot of attacks or issues that are passing API management gateways and also the so-called schema protection or positive security.
I will have a slide with more details later on that coming back of the, of the, of the transition of the web application security stack, let's say we need to have the visibility, I was mentioning it beforehand, We need to know our asset and we need to have robust inventory, but on the same side, it must be dynamically to, to reflect the changes between the revisions and keep track with the DevOps guys who have automations pushing APIs everywhere. So we need to have this transparency in order to protect. Then we also need API security testing and preferable proactive, right? So I will come back to this in a more detail also later on the, on the framework, which I would like to share with you. And then we had, as I mentioned, the API business integrity and data protection. And this is a topic which is quite interesting for technicians because when we take this example of the broken object level authorization, there is no violation of something, right?
We have a logical issue here. It's quite hard to build a security pattern, a signature, and to react on only one request here, right? You have to track, you have to find a subset of, of traffic, which is, which is malicious or suspicious. You have to find it. And then you have to take action and remediate it. And this is a good example of passing through API gateway and schema protection. You need for this dedicated API security solution, because the session is also, is also related. It has a weak authorization token in that way. But with this valid session, we have valid request, which doing malicious things, right? So an attacker could reuse the ization and the session itself if we do not secure the session. So you need a bunch of request to see the malicious behavior inside this session because this is a serious issue. If you could imagine if you have an attacker who is able to collect user data in, in this attack vector.
And another example of how it could lie would, could look like, or even about the transparency. I mentioned that I stressed it a lot. You need to have an inventory, a robust inventory, and also you need to have, or it makes sense to have the information which API is transferring sensitive data, right? So this will help you doing risk assessments, prioritize the application, prioritize the application security. If you also know which API is exchanging alternative data like credit cards, personal information, gdpr, things like that. This is when we put everything together. This is the framework which we apply in, in, in different, in different project, independent of the size of the customer, independent of the vertical of the customer. We take this, and this started, I stressed it a lot with a deep discovery classification of the data and being independent of ches. So a lot of security is foco focusing of schema files, which are prepared and, and provided by the dev teams. But that's not always true, right? So therefore we are also able to build this schema and, and doing the automated test on the discovered endpoints we have. So we are proactively supporting the teams.
This is when they're talking about the teams. This is also an issue slash challenge we have. So we see a lot of security vendors here. We have all great solutions, but what's not growing is often the teams, right? Due to lack of talents and the teams, You have five people, five masterminds, and now they have the API security. Maybe you are lucky and you have a dev guy who's supporting you in the security team. But the security machines or towards the security teams use must be easy to digest, let's say. Right? They should be automated as much as needed, but also should be able to get manual interaction with the security teams as well. And this is what we mention here. So we do an API specification assessment with our best practices. We have our own security and research team. We had a broad installation base where we can see what happened in the field.
We are updating constantly our patterns and providing the teams proactive with an assessment, how the schema is looked like, or we are able to build the schema based on the discovered parts and then doing one fuzzing test against your APIs, ideally before they go in production or before they are external exposed. But if we are come into the project and the, and the APIs are, are still there, we are able to, to do the discovery then and do it afterwards. And this is also an interesting slide where we see that projects often get stuck, right? So you have either the choice going into the cloud with a cloud solution in front of your environment, which makes sense. Sometimes you want to get rid of all the bad traffic, bad actors before they are entering your private cloud on premise environment, you name it. But sometimes you have API gateways and the so-called private APIs, they are externally exposed, but they had an, they had boundary, let's say, to customers or, or, or sending telemetry data to to, to, to other things.
And you have this one, right? You have the east and west as as well. We see a lot of Kubernetes right now. We need, we need, we see a lot of English controller. Maybe you want to integrate your API security solution logically as close to the application itself. Or even you want to see how microservices, so imagine you have a, let's say an application with a front up and a lot of APIs inside of this cluster, and you also want to monitor what these APIs are communicating or it's changing, right? Or when we are thinking about fedra installations, or if we think about air gap solutions from time to time, we are forced to provide air gap solution. And even in Germany, it's quite common. So you need to have the choice of your weapon, which fits to your need or even go the journey if you're starting here and then you say, okay, we, we are now going to the, to a cloud-based provider, right? You need to be able to, to choose and to add an independent layer over your environment, which is constantly updating
The information we have and which is integrating in your C I C D processes to the different stages we have run, test, and also build. We have the, the solutions in place. And this is what we also see that we are able to keep track with the DevOps DevSecOps dynamic changes of especially APIs due to the balance we've found being automated as much as needed. But also the security teams are able to manually tweak or interact with our solution at this stage. So I believe we have a few minutes left, so I'm done. Any questions?
Questions in the room? I don't have any online. Just quickly, I mean, in your experience, do most organizations understand the importance of API security?
Let's say part of the, of the companies are able, are understanding and are aware and some other parts not because some teams are more focusing on providing new services, new communication, and maybe are forced due to timelines We have Black Friday, right? So you need to have some services available on that day, not the day after and not the day before, even in that 24 hour. So maybe the focus changed a bit. I believe they are, they are aware, but if you get pressure for some other levels, so it's, it's depending, I, I believe most of the people are aware of the risk. Most part of the application. Sometimes we have people which are not aware, but when we go into the project and we can show the teams that they have shadow APIs, then they say, Aha, this is, this is then we have convinced them, let's say that there is an issue. We don't want to blame someone. We see the same, by the way, we see the same with databases. We have the same kind of shadow databases somewhere in environments because you have lot of them, every database has its own specialist. At the end. The companies are aware of these. Sometimes we have to show it. But yeah, normally.
All right. Thank you. Please show your appreciation for Jillian.
