The Dark Side of the API Economy

Okay, good morning. Good afternoon. Maybe even good evening. Ladies gentleman, welcome to another call webinar and our topic for today is the dark side of the API economy. My name is Alexei AKI. I am the lead Analyst at K call. And today I am joined by from the office of the city or at pin identity. Before we begin just a few words about keeping a call. We are an independent Analyst company headquartered in VIBA in Germany, founded around 15 years ago, focusing our research on all aspects of identity and access management, cyber and artificial intelligence.

And throughout these topics, we offer quite a broad range of research publications in other materials. And of course, like every other Analyst house we do offer your custom project based support in various aspects of your it or security strategies for your business. And as well, we are offering you a broad range of those events in the topics I mentioned earlier, events from free online webinars like this one today, all the way up to pretty well known and established and well attended physical events in all corners of the world.

And on this slide, we have a short summary of the upcoming events rest of this year. And of course, besides this one, do not forget about our flagship events, European identity cloud conference, which will take place next may in Munich as usual for the 14th time already, if you housekeeping words, you are all muted centrally. So don't worry about that. We are recording this webinar and we will publish the recording as well as the downloadable presentations on our website and every attendee and every register will get an email from us with a link tomorrow.

The latest you will have a Q and a session at the end of the webinar, but please, I encourage you to meet your questions at any time using the Q and a, the questions box of the go to webinar control panel, which you'll find in your top, sorry, bottom right corner. Probably our agenda for today is as usual structured into three parts.

First, I will begin with the general introduction into the quote unquote problem field or how API economy has been evolving and what challenges real life challenges companies are facing when dealing with insufficient secured APIs. After that, I will hand to front solar sale. We will talk about practical technical details or implementing by subject of API security using his company's solution. And beyond that, and as I mentioned, we'll have some time left for the Q a and let's just into API security. Why should we care about API at all?

Simple Porwal because of the world nowadays is connected, hyper connected. Even if you will, everything is now connected within companies at home, in between, on the move, whereas edge devices, various mobile devices, and just people carrying those devices around everyone and everything is connected. And all those communication channels are more often than not operate through some established standard based APIs, application programing interfaces. And those APIs have undergo an amazing transformation.

What started over 50 years ago, other pretty technical and technical concept targeted solid towards developers has over decades evolved into, again, some developer focused and very much technical and technology oriented protocols, platforms, architecture partners, technology stack in the last 10 years or so has completely changed the way businesses are like modern digital businesses operate.

What started in around two, 2006 with the arrival of the public cloud as quickly grown into a proper real life and very rich API economy where digital data is the product for many businesses and API is the logistics for moving those data around APIs are becoming the most used customer facing channel and the primary source of free for many companies. And of course, knowledge them in 2017. The renowned Forbes publication has officially proclaimed the year, the year of the API economy.

And unless this explosive growth has also shown us the dark side, the, the reverse side of the coin are all those multiple threats and new attack scenarios and exposure, vectors, and exploits, you name it, all those new risks. Digital businesses with open businesses are now facing through APIs as a new attack factor. So it would only be fair to proclaim this year, 2019, the year of API security, even if not completely official, at least this should be the year where you finally have to start thinking about it seriously, otherwise too late.

So on this slide, I collected just a few notable, really large scale data. Breachs where APIs are rather improperly secured APIs were either the main attack vector or kind of the most disasters channel to deliver massive problems to the company involved. And as you can see, it all started few years ago and the base is only picking up large and small. And even the hugest companies like TMA or Facebook, or even Oracle are no longer safe. Could you be the next one? Hopefully not. Let's find out how to protect yourself from that.

Actually, we decided to structure this webinar in a way that we will first start off. What could your company be doing wrong or other what other companies, including some listed in this site were doing wrong and how they, they were affected by those breaches and what could have been done to prevent them. And they will start with Instagram. It happened about two years ago.

It's probably one of the first largely publicized data breaches like API focused data purchase, primarily because it has touched millions of users and quite a few thousands of really high profile celebrity accounts, which were exploited and hijacked. What has happened as you can see, it all started pretty innocuously where Instagram has reported that there was a technical honorability, but it's all been already fixed. And only a few users have been affected nothing to worry moving on.

Unfortunately, just a few days later, it was been discovered that the hackers actually established in online database where everyone for low price of $10 per request could have a obtained credentials or email addresses and phone numbers of those high profile users. And of course, quite a few ne various parties have taken advantage of that. And there were reports of people being stocked online and their accounts compromised. Perhaps one of the most famous one was sort of just in BBER where some really unsafe photos were involved, but no lots of gossip, lots of speculations.

Unfortunately we never had any officially confirm technical detail. So we can only, again, speculate what has actually happened. Looking at the amount of data leaked was probably not the technical vulnerability, which could have been easily discovered and prevented. It would rather something like access controlled by password developer or employee account with incorrectly configured access, maybe even exploiting a partner account, which had unlimited access to marketing information.

Again, we can only speculate about the reasons, but the outcomes were pretty visible if only the company has not suffered any tangible damage, like fines, stuff like that. It was way before the GDPR times. But we do know that this definitely could have been prevented not by traditional security tools like application firewalls, because then again, nothing has probably nothing officially malicious has happened. The hackers has probably used hijacked accounts, just exfiltrated readily available data.

So only with some tools, automated tools would have been continuously monitoring those API endpoints, looking for anomalies. It could have detected unexpected volumes of the data going to an unpredictable place, not to one partner. For example, this could have at least detected the problem early, however, to actually make sure that these problems should not have happened in the first place. API security should have been integrated much earlier into the whole development life cycle.

Basically, if your developers have access to or have through their development or testing environments have full access to your customer's sensitive data, it's not the APIs. You are doing something wrong with, right? It's it's the basic security hygiene, the basic security culture within your company, or there's something to think about. Next one are arguably are slightly less publicized, but definitely more nefarious or impossible consequences happen a year later last August with again, very well known American telco operator T-Mobile subsidiary of the German der telecom.

It all started when millions of customers have suddenly received cryptic text message them to change their passwords. Many have actually taken this message for fishing or hacking attempt turned out. It was a real problem. It was a real data leak where international hackers have abused a weekly protected API on some kind of an internal website where employees manage the customer post information and millions of records have been leaked through that API, including not just customer details like addresses and phone numbers, but also password hashes.

Although the bridge was quickly detected, that is they probably had some automated security tools with security monitoring tools in place. It took T-Mobile too too much time to fix the leak. So really millions of accounts were leaked. In the meantime, again, the damage for the customers was obviously kind of many had many aspects, customer details, contact details are always reach. So for phishing and spa attacks and identity theft, but phone numbers and account data for telco customers go much further than that.

They enable multiple scams, which could lead you, which could leave you without control over your phone number and your account completely through texts like steam swapping, for example, but even more interestingly, the aspect that our, the passwords were hashed with MD five, they're well known and really outdated hash algorithm, which has been officially duplicated by just about every standard body and every security best practice. And those passwords were available through the API.

But to show that it's a massive design floor in just about any system, whether it's internal only or customer facing. So the problem again were not at the API level. They were much earlier in the developer culture than the company, but even more so understanding that the security coverage, the API security coverage has to be expanded to every aspect of your API infrastructure, whether it's believed to be completely internal and not exposed to the outside world security security does not work. Next one, that's really interesting case.

Or again, later in 2018, Facebook has announced that they have actually managed to detect and prevent an API bark, which could have been potentially used to, to let anyone to take over any other user's account on Facebook. It actually involved a rare combination of three different bug and three different subsystems of the Facebook website, including the so-called us function, rarely used obscure feature, which you could have used to check how your own Facebook profile looks to other people.

And the rare, the multiplication of access tokens generated for trans scopes could potentially lead to catastrophic consequences where anyone with the browser could have kind of performed the chain attack, taken over more and more accounts. In total, it has affected over a hundred million users who were not breached or damaged somehow, but at least they were disturbed. They had to be contacted. They had to be informed. They had had the talkings revoked and the was the us feature remains disabled till this day.

Again, possible prevention or includes better development of security standards and explained application securities. Again are APIs here are, especially those trivial obscure APIs, which the developers probably believed almost nobody is ever using, or they were used as an amplification for other attacks, which has led to catastrophic, potentially catastrophic consequences. And the lesson here in that are no API is to trivial to be left unprotected again in the game.

And of course our head Facebook already had more modern application architectures like microservices, for example, in place, at least the, the potential impact of that bug would have been much, much lower. And the last one, the last real life scenario for today is us post services back home.

Again, last November, independent security researcher has published a vulnerability on the USPS site, which allegedly has been exposed for at least a year. So for a year, he has been waiting to publish it, have been trying to push SPS to fix the problem, reaching them multiple times, or unfortunately the company has ly refused to even acknowledge that the problem exists until Brian Krebs very well known security journalist to weigh in with his reputation.

So to say, and only then they have finally found time and resources to fix the problem shortly before it was publicized. Apparently their online web service used to inform customers about the current status of their packages could be abused by any users to get access to any other user's accounts, not just a single user, but they could run wild queries, getting access to thousands, if not millions of other users' identities, addresses accounts, and even modify some of their information. Like for example, pick up delivery addresses even worse.

It has been known and that the USPS had absolutely no security monitoring or audit trail in place. So they, they were simply enable to historically say, how many users have been affected or which data has been stolen. There had simply no trail on that. The damage was really impressive. And I am a bit surprised that this, this, this case was not that medically publicized, that this data is very well known to be used for multiple different purposes.

For example, for intercepting packages, for registering credit cards, fraudulently for other people's identities, and then stealing those cards and spending the money living multiple victims of identity theft with have to bills. It was even investigated by the us secret service, apparently even before it was publicized.

However, it's, I am not aware of any legal proceedings, at least the public legal proceedings at the moment. And again, asking what could have been possibly done to prevent this kind of, kind of borderline criminal abuse, the criminal negligence, no, nothing really.

I mean, if, if a company is missing, even the most basic understanding of cybersecurity, hygiene principles, little can be done to fix it, don't be like us Ks. That's my lesson for you today on this slide, I have collected just some of the major risks which every company dealing with APIs is to consider. As you can see, it covers not just actual endpoint, not just the network interface, the rest or soap or any other protocol endpoint.

It actually spent the whole technology stack from the very low level, even hardware level to communication level transport to multiple payload attacks, which exploit API schema violations, API contract violations, for example, or lacking proper input validation, SQL and Jackson cross side scripting logical bombs where the data fed to an API input looks valid to any traditional application security, sorry, application firewall, but can destroy the, the backend behind the API. And of course the human factor is never to be taken too lightly.

If a developer has no too little understanding about security by design well, best practices about not leaving hard, coded credentials in know, API, client implementation and stuff like that. All this has to all this leads to risks and all the unmitigated risks lead to breaches. And as we can see, more companies small or large is immune, unless they invest properly and heavily into API security strategy. And on this slide, I try to summarize again, kind of the bro, the breadth of this scope of API security, which covers so similarly separate topics like discover and classification.

Obviously you have to know which APIs you are protect your own and third party APIs, your business partners, APIs internal and external ones management APIs for your devices like office printers, administrative APIs for let's say ate or your cloud service provider.

All those are potential threat vector, and all those have to be discovered and monitored and secured access control, consistent, fine grained, again, across all scenarios, all services, not just APIs, data validation, schema, API contracts, policies, each input and output parameter has to be validated according to basic business logic, basic security and compliance policies within the company. And of course, some industrywide best practices and threat intelligence, same applies to flight protection. API endpoints are just as open should I say?

Improperly secured endpoint are just as open to very smallware exploits, UHS and vulnerabilities as say email or databases or unprotected websites. And of course, transport security are encryption network. Isolation is goes all the way deep down to infrastructure level.

And again, it has to cover both your internal, physical infrastructure, like on-prem your virtualized infrastructure, your containers, your cloud services, and your even your partners services as well. And all that's rounded up with analytics automation with all huge amount of security data, which all this are aspects or for API security tools are delivering any team of human Analyst will be buried plows or even millions of piece of security data. You simply need to have AI and machine learning based solution hand to sift through all that critical noise.

And to give you a low number of the most critical, the most risky incidents to investigate and to mitigate as quickly as possible. Although that would be my last slide for today. What are the general recommendations from an Analyst?

Again, no technology alone help you. If you don't know what you're doing. Education here in the key awareness for all stakeholders, starting with developers and testers, ops people, security people, the board, the C ideally even you're part of in customers in very specific cases, they all have to be aware of the patents best practices and general guidance. You always have to start with a strategy. You have to understand your current and potential future risks. Nobody will understand your kind of your specific businesses impact for each of those risks. You have to do it yourself.

And according to the strategy, you can start building your multilayered API security infrastructure. Again, you have to know what you're protecting, discover, or classify and monitor all of your APIs, not just all APIs within your infrastructure, not just your own APIs.

Again, avoid silo approach. Do not think that you can make API security as standalone solution within the, the, the bigger picture of it security within your company. It has to be integrated into the bigger security architecture, API zero trust, or it's a nice term, which simply means to that, that an API without identity cannot be not just properly protected. It cannot be even properly monitored, no traditional or even old school security tool, which has no understanding of identity like a wha application firewall justifiable.

When anti can help you secure API APIs properly last, but at least as I mentioned, API based automation is your friend. Those solutions cannot replace humans, but they will benefit every aspect of your security and daily work being detection, orchestration, forensic analysis, and even practice mitigation for developers. And this is where I stop talking and give the stage to frontal cell Fran. It's your turn now. Thank you. Alexei. Let me just start with, I like these third point here, which is know what you're protecting.

This sounds like a very basic thing, but we, we run into a lot of customers. That's, that's exactly what they're struggling with. Our customers are not confident that their security teams knows about all the APIs that are in existence in their organization, right? So there's been a proliferation of APIs over the last decade and that's creating a blind spot for security team. We actually had a, a survey on that where 51% of responded claim that they did not have enough visibility on their API.

So that's, that's the first problem that I'd like to call out. So there's for example, old forgotten version floating out there, right after 10 years, you've gone through a number of revisions and there may be older versions of your API that, that kind of like fell off of your radar and you're not paying attention to them anymore, but more importantly, there might be APIs that are falling outside of your formal API management infrastructure, your formal API management practices. They may be coming from another department.

And for, for whatever reason, people looked at these APIs, well, we don't necessarily need to secure that this is public information, but then, but then somehow some information that's critical is going through these APIs without, without the proper vetting bias security team. So the lack of visibility is really one of the big problems out there. One of the challenges obviously controlling access to your APIs, right? So urate must authenticate users must authenticate applications. We talked about zero trust there.

So we need to validate access control to each API resource based on modern tokens, things like jobs. So you need to implement that across all your API endpoints.

That's, that's no small fee. You need to a way to centralize define access control rules, and you need to enable all API endpoints to validate these tokens and, and enforce these access control rules of the big priority. And as data control your data is flowing through APIs, right? So you need to enforce fine grain authorization to customer data, being accessed through your API, by an application. And that's, that's different than controlling access to resource. We just talked about earlier.

You need a way to define and check and, and enforce complex and dynamic rules and, and customer consents to properly protect sensitive data in APIs. Those are very dynamic. Think about a customer granting permission to an application accessing maybe this type of information, but not that type of information. Those things are dynamic. I might change my mind.

I might, I might authorize an application, you know, temporarily only, and, and you can't trust your backend services to properly enforce those rules for you. Now, the, the third problem I wanna talk about is the cybersecurity thread. APIs are becoming the most frequent attack vector for data breaches it's. And if you think about it, it makes sense. This is a very attractive attack, vector or hacker. And if you, if you notice the breach reports that are coming out, like almost on a monthly basis, these days, you, you notice that breaches are actually going undetected.

For months, sometimes years, we talked about Facebook, took them over a year to figure out this breach, Google with Google plus, and an issue. It took them over a year Marriot last year. It took them four years to, to, to detect and stop that, right? So there's blind spots in your foundational API security, and that is leading you exposed. And so the cybersecurity threat is very, very big. So if we summarize this, here are the four challenges that I'm going to talk about solution for.

So visibility, you need be better visibility for APIs across your distributed enterprise, better visibility on attacks, right? If, if there's an attack happening, you want to know about it, access control, you need to coordinate resource level access control across an explosion of API endpoints. If you think of microservices, microservices, for example, you're breaking the model into all these different API endpoints. You need to coordinate access control over all of that data control. So data flows through your APIs. It needs to be filtered.

You might need to re redact in order to comply with complex and dynamic rules and consent are coming from your users. And then finally, cybersecurity API abuses use things like stolen token and vulnerabilities that are other factors outside of your APIs. If you think about it, you know, the vulnerability is not necessarily your API. It can be your users, your users are gullible. They can be tricked into fishing attacks.

If you think about what happened last month, when there was this study that, that talked about all of these client secrets on GitHub of GitHub, client applications are not always in your control. They're calling your API. So if you're sharing a secret with a client application and you can't trust this client application to keep that secret, how, how are you going to protect yourself, right?

This, this is a, a massive cybersecurity issue. So being identity has three core products to address API security.

And, and those are three products that I'm gonna focus on this presentation here. So ping access is the first one, a top left there, and this is really about controlling resource access to your APIs. And then we have ping data governance, which is about controlling. The data that slows through for is about giving you visibility on your well as an AI based attack detection and blocking. So let let's dive in here. So resource access control. So P access is going to evaluate and apply access control policies against the host and passes of resource, right?

And there's, there's a, an illustration here. This is what it would look like in paying access. So ping access is going to use the identity and there could be multiple identities, right? Identity of a user of an application. And that information is, is pulled from any token format. It's gonna mediate between different token mechanisms. And it's going to also mediate between disparate authentication mechanisms using site authenticators. So between the front end and the back end, and it will protect the intersection of web applications and API.

So if you think about a single page application, which is kinda a combination of a web application, as well as an API, which is a very common pattern, P access is very well suited for controlling access to these types of applications. So we'll transitions a single application from, from to data governance about, as the solution for data control is really operating at the API plane. So if you think about the API plane, you've got a plane where you've got API, you've got from the API traffic structured data, right on the outside from the outside world. This is what your data looks like.

It looks like adjacent structured data. It doesn't look like tables and columns and things like that. So it makes sense to apply access control at that level. So you're leveraging that structured data and rules are defined around it. You've got an identity context, that's preexisting because are attached to your traffic. So you've got this combination of structured data, your identity context. And then you add to that these external sources, so P data governance and at runtime is going look up user profile consent information in a dynamic way is going to consult policy decision points.

And then at runtime, the data is checked, right? So we can authorize or, or deny access to data, but we can also filter in transit.

And, and in this open banking example that I'm here. For example, maybe an application has permission or consent to see this, this summary about a user account, just at the balance, which branch and, and, and which currency, but maybe it doesn't have access to transactions. And this is something that's di dynamic and, and think data governance would do that in front of your API, backend dynamically at runtime. So ping data governance really allows you to centralize data, access governance, control it, external externalizes policy administration to business users, instead of developers.

It makes it easy for business user to author these access control rules. It enforces customer data, sharing consent for regulatory compliance, and here's an illustration of thing, data governance. So it governs access to your entire resource or individual attributes. It gives you the ability to delegate this resource management and it enforces customer preference, you know, or the optin or opt out choices across all your channels. So this is done in front of your API backend, or a more dynamic data control, and then visibility.

The, the visibility problem that I was talking about is really addressed by intelligence for API. So you get this consolidated API traffic visibility. And the reason is that you can attach intelligence for API at any API entry point to maximize that visibility on all your API traffic. So when you're low balancer, for example, if you're using EngineX, you can attach free intelligence for that. If you're using Amazon for some APIs, you can attach intelligence for APIs on your Amazon cloud front. We support all of the major API gateway technologies out there.

So you can attach the intelligence to each of those API gateways, and you're getting this consolidated view of your API across all your, and this helps you discover APIs that may not be on your radar today. We we're giving you this added view of your API, and we're doing that from the lens of the API traffic, which is a different perspective. Even for organizations that have a formal API governance practice in place at the moment, you, you will gain a benefit from having this additional perspective on what APIs are out there.

And then finally, APIs is going to give you forensic information to help with incident response and re regulation compliance. And what happens is that, you know, after you've been, after you've gone through a breach, been detected, it's been stopped, that's all great, but you need to go back and find out, you know, what damage occurred up to the point where we were able to detect that and block S is, is, is going to accelerate the incident response and, and help you repair the damage, notify the right people that have been affected by a breach and then cyber security.

This is where intelligence has very innovative solution. We're using machine learning and we're applying it to your API traffic. So the idea is that S for APIs uses machine learning to build model using your API traffic, right? Machine learning is about using big data to create this mathematical model that allows you to make predictions while in this case, the, the big data is your API traffic. And if you think about it, your API traffic is already there for you to leverage and, and build a small out of it.

So you should take advantage of that, and hackers will use your API outside of your app and, and they will poke around and they, they, they, they will look for vulnerabilities and then they will exploit these vulnerabilities. And that stands out from that model of your traffic when your traffic is incoming from your legitimate applications. And that's how P intelligence for APIs has the ability to detect a region progress. And then API attacks are automatically detected and they're blocked by intelligence for APIs. We would also issue alerts.

So here's an illustration, for example, where pig intelligence for API would notify you in a slack channel that an attack has happened. And then intelligence for API is actually gonna go back and, and, and block the attack by updating a blacklist on an API gateway, for example, and this, this is another strategy that P intelligence for API leverages to block attackers in, in a very clever way. And if you're familiar with judo, you understand the concept of leveraging an attacker's strength against them, right?

We, we talk about APIs and this is really about leveraging the hacking behavior against the hacker against the attacker itself, right? Hackers will, will poke around and, and look for vulnerabilities. Look for endpoints that may not be secure in a way that your applications don't, your applications don't do that.

They, they, they only know about the APIs that they know about that the developers embedded into the application. And so when a hacker pokes around and falls into one of the, the traps, one of those decoy APIs, we're going to be able to instantly flag that request, right?

We can, we can just reply 200. Okay.

So that, that the hacker does is not aware that this is a trap is not aware that they're being flagged, but as soon as they hit one of those traps, P just APIs is flagging that requester. And then whenever the same request or tries to hit a legitimate API, we, we can block access to that real API.

So that, that makes it even more real time if you want, because with machine learning, we're, we're taking an attack detection that, you know, traditionally these days, like I was saying earlier, will take sometimes in months to be detected. We'll bring it down in two minutes. In this case of, of using deco API, it's, it's an actual, real time detection and blocking. So let's look at an example, API flow using those thing, identity products. And the example that I'm gonna be using is an open banking example.

You've got a financial aggregator application and something that you would see a lot in open banking. So you've got this, this third party application here. This is your financial aggregator. And then you've got a customer who's a customer of this financial institution. And this is what it would look like to this customer when they're going into this third party application. And then the user would click here to connect an account on his financial institution. And the financial institution would be using ping for their API security. Here's their API.

And here are all the ping products that are involved in here. So the first thing that happens, user clicks on connect account, what happens?

Well, the customer is redirected back to their financial institution in order to grant access that third party app. And so what happens is that that through pink, which is really the oof authorization server, which is starting point of the API flow here, pinked is going to orchestrate this whole a handshake. And so the user is going to consent for their account to be accessible by this aggregator, this consent. And all of the details of that consent is recorded in ping directory.

And then if, if, if the, the, the financial institution in case any bank is deciding that, you know, this is the first time that you do this, this, this type of consent with this third party application, we're actually going to step up these education. So there's a multifactor authentication here. That's involved as part of that handshake. And this is where ping ID tends in. So ping ID is going to facilitate that multifactor medication P ID can actually be embedded in the native application. And so this is the, the first part of the, the flow here.

And then when the user accepts this thing and, and, and is redirected back to the third party application, the third party application then goes to Peder to get that token. So now this, this third party application can start calling the API at a financial institution. And so now we're, we're moving from the oof authorization server to the resource server.

And, and when that happens, paying access is going to be the resource level access control and ping data governance, which is also living as part of that resource server is going to control the data coming in and going out of that API. And then while all of this is happening, and you see the result here from the user experience perspective, their, their transactions are being, are being showing up on that financial aggregator here.

But while all of that is happening, pings for API is monitoring that traffic in this case, pings for API is getting information about the API going in and out via ping access. And in that, that is basically allowing things for API to report on the API usage it's updating and building a model for normal API traffic, so that the model is up to date. And then later on, let's say that there is a malicious user that is abusing an API P intelligence for API is, is really going to detect that. So an API abuse is generating traffic, API traffic. That's inspected by P intelligence for API's AI engine.

And by the way, that's them all out, right? We're not affecting your latency, but this is going to stand out that there's gonna be an anomaly. That's gonna be detected. Alerts are gonna be issued. And in P and intelligence for API is going tracking access to blacklist. In this case, it could be the token associated with a user, right? If this was, if this was pre-authenticated traffic, and there was no token, maybe an IP address would be blocked or a cookie, we can block on a number of different factors. So the attack is blocked.

This way, reports are generated showing the attacks and the forensics and everything. You need to react to that. So again, to summarize three core products from identity, to address your API security, ping access, to control resource, access, your APIs, ping data governance, to control the data, launching through APIs S for API, which is really about giving you that API track visibility, as well as your, an AI based attack detection and blocking for your APIs. And we do have 4 billion, thousands for APIs, a really simple way to try it for yourself.

If you want to start playing around with building a machine learning model for API and seeing the benefits that gives for you, you can do the simple POC with all of the AI aspect hosted by ping identity in the cloud. So we're running pal for API in the cloud, including the dashboard, the AI engine and everything like that. And then on, on your side, your API gateway, for example, and, and we support all of those API gateways, all you have to do is install the API security enforcer. We call it the ASC, which is thin agent that runs alongside your API gateway in a side van mode.

And then from that, you would be able to, you know, very quickly get some dashboard and some reports you can turn on blocking mode if you want, or just see what type of insight you're going to get from the API. So I, if you're looking for that, just Google intelligence for POC, and you'll be able to access this still few minutes left for Q Fran, this comprehensive technical explanation of how my simple ramblings about theory can actually be translated into solutions at work.

And yes, we do indeed have some time left for Q and a. So please submit your questions using the tool. And the first one we already have are, let me just read it out for you. So API security tools have been in place for over a decade. So why are we still seeing so many bridges? And if you let me just say a few words, I have to respectfully disagree. Although some API security tools did exist for years already.

Those are, if you remember that diagram, I've shown you the scope of API security, where you have to have to care about almost a dozen of different attack vectors and technology technologies and solutions. So yeah, some tools have existed, which could probably cover one or two or even three, or those vectors for a specific deployment scenario. For example, if you have an on-prem API in your bank, you would put a, an appliance, an API security appliance in front of it, and it would work without work in the cloud or for a microservice based solution. Definitely not.

So new developments, new technologies needs new solutions. Those solutions can only started to appear on the market for maybe the last two or three years tops and why we have some.

Yeah, Yeah. I mean, from my perspective, I think that, and, and I've been personally involved in building security tools for ICD for well over a decade.

And, and it's true that there's a lot of sophisticated tools out there, you know, for example, in API gateways, I think the reason that, you know, there's two reasons, I think while, and, and I alluded to some of them in my presentation, why, why some breaches still happen? So, first of all, I think that, you know, very sophisticated API security tools sometimes will require very sophisticated human operators to, to set up these rules, right? The static rules that would allow you to detect and block an attack.

And there's just not that many people in, in your organization that have the right combination of knowledge. You know, if you think about those are humans that understand what your API does, what your application does, people that understand how your API infrastructure work. There's just very few people with all of that knowledge.

There's, there's a shortage. There's a shortage of that, that human input. And you were talking about the human factor Alexei. So that's very good example of it, right? If you don't have enough people to think about the static rules that would be needed to catch something, then you're maybe not taking completely full advantage of the tool that your disposal. So that's one reason that human factor.

And to me, the other reason is that it's not fair, but you know, the vulnerability very often is not on the API itself. The vulnerability can be on the client side, like I talked about, right? You can't trust your client to keep a secret. So what are you supposed to do? It's not really your API fault, but there are using machine learning. That's the good news. You have an ability to still detect that there's an attack in progress and block it. So look to me, those are two reasons, Right? Right.

And of course, again, as I mentioned, the market kind of the digital transformation is still ongoing. So there are constantly new technologies popping up containers, for example, or serverless in the cloud, serverless computing, there are new software methodologists like microservices, all those new developments, they require security tools to be adapted. So if you buy your API security solution today, tomorrow, it'll be useless, right.

If you don't buy the right one, the flexible one, the extensible one, it can plug into your existing kind of multi-level security infrastructure that can be quickly adapted and expanded by the vendor. So that, that's one of the biggest challenges. The market has definitely so many more products to offer today than, you know, three years ago, but it's still up to the clueless, sometimes clueless customers to, to find the right combination of those tools. Okay. We have time for one more question. What's an example, blind sport when it comes to API security. Yeah.

I've given an example that, that, that came from a, a customer gonna mention what the customer is, but they, they had a situation where they, you know, there was a team that had a mandate mandate to create this new, modern rest, Jason API, for whatever purpose, right? At, at implementation time, the team decided to use a, a legacy.

You know, they had a, a legacy XML based service that did very similar things, and they were able to leverage that in, in, in the background. And, and so that, that was a legacy service from their, so, so they, they put that thin layer, rest service. And then on the receiving end, they would translate from the Jason rest API call to the soap calls on the back end.

And, and they did the testing according to the design and that modern rest API, everything was good. But what happened is that there was something that was not hooked up properly. And if you sent requests that new endpoint with the legacy format, that that thin layer that was added was just skipped over and including all of the access control rules, right? So this whole soap to rest pattern that you see everybody doing. So it's a why that a blind spot, it's a blind spot because it's not part of the design, right?

This isn't an implementation detail and the testing team, they're not aware that, of that implementation detail of that, that legacy XML service. So, so that was not part of their security test scenarios.

So that's, to me is a simple example of a blind spot. One that, you know, should keep you up at night. That kinda stuff I wanna argue, it's actually more than one blind spot, because if there is a way to bypass your access control through some data manipulation, can you actually be sure that you cannot bypass it at all through a testing environment, through an insider rogue developer, for example, or any other attack vector for so many things to consider?

It's like, again, it sounds almost like that USPS case with Yeah. Well, if everyone is so clueless, the whole system would just crumble upon its own weight. So what to say?

Okay, exactly. Well, that's probably not the most optimistic point to finish out today's webinar, but again, if there is one takeaway from today's webinar for you, the attendees that don't be like those people, education is key awareness is key. Stay up to date, talk to us at any time, talk to ping at any time, we are always ready to offer you guidance and the best practices. And thanks a lot for being with us today and have a nice day. Thank you.