Protecting APIs has become really critical to enterprises as we've shifted from traditional monolithic web-based applications to containers and PaaS services and really trying to build better digital experiences for our customers, and the consumers within our different verticals.
The way we protect APIs has to be inherently different from the way we protect web applications because APIs are abused in different ways and it's actually more that you are attacking the business logic behind the API than you're attacking the application itself.
So for all organizations, the first and most important step is really understanding your inventory of your APIs. And you'll see here, inside the Akamai API Security solution, immediately we show you the number of API hosts in the environment, the numbers of APIs, the data that's being exposed from those APIs, and the different types of APIs.
Are they REST APIs, are they GraphQL? What are the different types of APIs in your environment? You'll also see the types of authentication and you'll see some API classifications as well in this widget down in the bottom. If we click on this API view here, we're actually going to see the full list of the APIs now.
You understand the host, the method, the path of the API, a risk scoring based on our findings associated with the API, any incidents, whether or not we detected authentication, whether or not the API is Internet facing and the different types of data that's exposed.
This is probably the most interesting part of what you can see when you look at the inventory is what type of data is exposed. Because that's where we end up in the world of data breaches is when we have APIs that lack authentication, they're internet-facing, and attackers have the ability to extract sensitive data from them.
So you can quickly see that in this API here we see some PII and some sensitive data. And more specifically under the data type, we see email addresses that are exposed, or we can see here we have passwords that are exposed, we have credit card numbers that are exposed.
So you get a really strong view of the list of APIs within your environment as well as the data types that they're exposing. Now we also monitor the changes because your developer is going to make changes to these APIs over time. And with our monitoring of the traffic we can quickly show you what's changing on these APIs.
We can show you some field changes, new data types, changes within the header, as well as if there are any changes to the methods in the way that these APIs are actually called from the source side. We can look at a more specific view of the data types that are being exposed, if they're being exposed in requests or responses, and how many requests and responses they're being exposed in.
We can look at the consumers, show exactly who is accessing your APIs, where they're coming from, what are the user agents they're using, what are the locations that they're coming from as well. And lastly, a snapshot of your infrastructure. Where are these APIs actually running within this environment?
In this case, we're running in a Kubernetes environment. Being able to build your full inventory of your APIs is the first step in being able to protect them. We call this the first pillar of API security. This is critical for all organizations just to understand what they have within the environment, because we can't see what we can't protect.
The next pillar of API security that we're going to talk about is around runtime protection. And this is our ability to protect and understand how attackers may be manipulating our APIs that are running in production and looking for things like weak authentication or no authentication on an API, looking for an attacker that may be trying to access or manipulate an API to access someone else's information and ultimately resulting in a data breach.
So what you see on the screen here is a real quick snapshot of the findings based on the severity as well as the different attacker groups that are accessing the APIs. Here in the middle is a really important part of this screen. We're looking at organizing the incidents based on the OWASP API Top 10 framework.
This is relevant because, as we previously mentioned, the way you protect APIs is different from the way you protect a traditional web application. So OWASP actually released a very specific list of 10 potential vulnerabilities that API specifically may be vulnerable to that are separate from the traditional OWASP Top 10 for web applications.
Let's take a look at some of these findings. So first, let's just start with some incidents that we've seen. Here we can see a real quick view of all the incidents within the environment, the time they were detected, the type of incident, what API was triggered on, the severity, the current status, as well as the last activity, because the first time it's detected and the last time that we've seen an attacker poking at this API could be different.
We also see an attacker confidence score and we can drill in deeper to understand exactly what's happening. So here we have an API access attempt with missing authentication. You get a breakdown of exactly what we saw in detail, why this is a problem, and what you should do.
You can also look at the API information, information about the attacker, IP information for where that attacker is coming from, and get a full understanding of exactly what happened in this incident that led to an attacker accessing an API that's missing authentication.
Let's take a step back and look at probably the most impactful attack that we see on APIs. This is called a Broken Object Level Authorization attack. And we'll see here in our environment that we actually see 13 incidents related to OWASP API 1, which is Broken Object Level Authorization.
We can click and take a look at one in a bit more detail. Now, we see here the same level of information, but what's really interesting to look at is when we click on this first incident here, we get our same snapshot of exactly what occurred. But what's really useful for your teams and actually resolving this is the evidence.
So what happens in a Broken Object Level Authorization attack is the user has actually authenticated to the API, but then they are manipulating the API query to change some parameter to try and access someone else's account or some other information.
So as we look at what's occurring here, we can see that within this API, under the orders parameter, this user keeps changing the order number. So it's clear based on building a baseline of normal, that a normal user should only access one or maybe a small subset of order numbers within this platform, that we're seeing someone cycle through a bunch of different order numbers trying to access sensitive information for other users of this API.
You can see the full request and response. On the left-hand side here, we have the full request that was sent. On the right-hand side here, we have the full response. The real bad thing we see here is the response status code is a 200, which means that in this case the user actually received back the potentially sensitive information that this API has related to these order numbers that they're cycling through.
Now the nice thing about what Akamai API Security offers is you can take action on this user. We can click this Action button here and we can choose to block this attacker and block them based on their IP address. And we can send an alert to the Akamai web application firewall to actually take an action and block this user the next time they try and access your API.
You could also send emails to your ticketing systems for your SOC team. You could send emails, or notifications to Jira, and other solutions to notify development teams of what's occurred here. But ultimately we're giving you the opportunity to not only understand that there was an incident, the details of that incident, and the ability to take action against that incident.
All of this is really core to ensuring that you have proper runtime protection on APIs, because these APIs are already deployed in production environments, which means the attackers already have the opportunity to access them, manipulate them, and potentially breach data from within your environment.
Okay, lastly, let's look at reporting here. So we look at reporting from two ways: compliance and security. Looking at this compliance reporting dashboard, we get a really quick snapshot of our compliance score and any findings associated with the compliance regulations.
In this case, we're looking at the framework just from the OWASP API Top 10. But I can look at this from different frameworks as well, including, we'll take an example of PCI DSS 4.0. There are specific requirements within PCI DSS 4.0 where API security solutions help you understand, help you meet those requirements by providing a full inventory of your APIs, monitoring the data flows and how users are accessing those APIs, and looking for vulnerabilities such as missing authentication or poor security posture of those APIs.
You'll see here we have a compliance score that 68.43% of our APIs are actually compliant, which is a good thing. But we still have some noncompliant APIs. We see the findings, we see how many findings have been detected, as well as how many have been closed.
This gives us a really good view of how are we doing in addressing these findings associated with PCI. And then you get the full list of all the open items listed by severity as well as the actual control that they are associated with.
So we see a control here about protecting stored account data. We have some open incidents associated with this. We've seen some changes over time where we've seen less incidents, which is good, means we're addressing those findings. But we've also seen an increase in medium-level incidents here.
So we do have some work to do to clean this one up. But these compliance dashboards are great for helping you understand exactly your posture as compared to the compliance regulations such as PCI, NIST, ISO, or OWASP API Top 10 2023.
Now we also have the security dashboard for reporting and this gives you a snapshot of your security posture and how you're doing in protecting those APIs and where are they vulnerable to different types of attacks. Real quick executive summary up top here. Then you get that full list of the OWASP API Top 10.
You can tweak this over time and let's see what this looked like from a week ago or from two months ago. And then you get the full dashboard findings associated with the different incidents, what data is being exposed, posture findings, etc. If you'd like more information about how Akamai API Security can help you and your organization and your specific challenges with addressing API security, please feel free to scan the QR code on the screen.