APIs are a massive concern for our customers and organizations worldwide and I’m sure you know we have had some API security capabilities within WAAS. However, in our latest 22.12 release, we’ve added more innovations to this feature. What we’re adding is the visualization of all risks associated with the API to prevent attacks that can occur through risky and vulnerable endpoints. So at first, you were able to discover all APIs in your environment, and now we’ve added an additional layer to help prioritize risks by adding in more risk factors. For example, adding capabilities to notify you if APIs containing sensitive information are exposed to the internet. From there we’ve added more insight into vulnerabilities within these workloads, all on the same screen. This helps you prioritize the APIs that contain the highest risk and then add protection for these APIs.
Our goal with WAAS is to address the underlying security. Addressing just the tip of the iceberg isn’t enough. What I mean by that is it is one thing to identify risky endpoints, but what about the rest of the application? How can you secure the entire application? With our latest innovations and continuous efforts, we are the only security company actually addressing the rest of the iceberg.
To showcase the importance of addressing the security of your entire application, going beyond just API security, let's take a look at a real-world example.
In this diagram, a security provider experienced a ransomware attack that originated from an endpoint that was open to the public. Anyone could have sent a call to that REST API endpoint requesting contact details for a customer with contactID. That contactID was directly referenced. One of the best practices here is to randomize contactID and then map that into a real contact. Then finally what happened is the attacker was able to enumerate and exfiltrate millions of customers' data and personal information from their database.
Now, how did this ransomware attack occur and how could it have been prevented? There wasn’t any validation regarding who is authorized to access this API. There was no request tracking or any sort of rate limiting. With our core WAAS capabilities, we are able to provide that type of protection and more than just detecting vulnerable APIs, we’re able to prevent and alert you on these types of attacks.
With our latest release, we have made tremendous strides in protecting your personal and sensitive data using WAAS and API Discovery. Bad actors are getting better and better at stealing sensitive data and we’re here to put an end to it. One of the key features we are going to discuss in this blog is utilizing a well-known feature, API Discovery, in order to protect your apps. This includes a new feature called path risk profiling, which helps identify vulnerable API endpoints when it comes to sensitive and personal information. Another great feature we will discuss is utilizing API Discovery to create sensitive data rules.
A powerful feature within WAAS is the API Discovery feature, which automatically learns API endpoints in your app, shows a report of endpoint usage, and also allows you to export all discovered endpoints as an OpenAPI spec file. When API discovery is enabled, Defender inspects API traffic routed to the protected app. Defenders learn the endpoints in your API by analyzing incoming requests and generating a tree of API paths. Every 30 minutes, Defender sends Console a diff of what it has learned since its last update. Console merges the update with what it already knows about the API.
Although API Discovery is enabled by default, take the following steps to ensure it is still enabled on your protected app:
Once API Discovery is enabled, we can begin inspecting those discovered endpoints. To find these reports, head over to Monitor > WAAS > API discovery.
We have completely revamped this page to show more information that can help protect your applications, not just for API security but showing how many vulnerabilities are also present in your workloads. Here we see very important information such as the actual path, what HTTP method was used, the number of hits, API Protection status, path risk factors, as well as the workload, along with other information. To view more stats on an endpoint, simply select the path. This view will give you more information pertaining to that particular path.
A new feature we have introduced in 22.12 is path risk profiling. This feature displays visualizations of all risks associated with APIs on one screen. This new feature allows us to identify three critical risks when it comes to API Endpoints, as well as identify vulnerabilities within those workloads.
1) Endpoints that are accessible from the internet.
2) Endpoints that do not require authentication in order to access.
3) Endpoints that have sensitive data such as credit card information, PII, emails, session cookies, etc.
This feature is a great way to identify risk endpoints as well as filter risk by workload vulnerabilities.
For example, in the below screenshot, in the “Path Risk Factors” column, you will notice four icons for the path, “/login” which is detecting vulnerable API endpoints that are exposed to the internet, APIs with sensitive data, and APIs that allow unauthenticated access to them, and if there is an OWASP attack detected.
Now that we have identified vulnerable endpoints, now what? The next step would be to actually protect these endpoints with path risks. Under the Actions column, click “protect” and here you will be able to set effects for all API endpoints discovered in that particular app.
Now let's go beyond the tip of the iceberg and actually address those risky API endpoints. A great way to flag your apps that may include sensitive and personal information is by creating sensitive data rules. The reason why this is a big feature and can play an important role in protecting your web apps is that there may be sensitive data captured when WAAS events take place, such as access tokens, session cookies, PII or other information considered to be personal by various laws and regulations.
By utilizing sensitive data rules, you have the ability to mark sensitive data and enable log scrubbing based on regex patterns or its location in the HTTP request. Keep in mind, when we flag sensitive data in API Discovery, we won’t automatically scrub that information in the logs. To accomplish this, we have the log scrubbing feature that will scrub the data and replace it with placeholders. This way the actual information isn’t being passed through the logs, where bad actors can intercept this data.
By default, we give you some common out-of-the-box rules to get you started. However, you still have the ability to create a custom sensitive data rule.
Let's walk through how to create a custom rule:
Example of what log scrubbing looks like:
Allow the WAAS module to observe and update new API endpoints from your environment. This is a great way to ensure maximum protection against your web apps so that way you’re not having to look for new endpoints yourself. Not only does this feature discover new endpoints but will create usage reports as well.
A new feature in our 22.12 release is the addition of path risk profiling. This feature allows us to quickly identify endpoints that may result in sensitive data being leaked.
Protecting your sensitive data is very important to us, so on top of just implementing log scrubbing, you have the ability to create sensitive data rules as well. By utilizing these rules you have the ability to mark sensitive data and enable log scrubbing to replace the data with placeholders in the logs before the events are recorded.
You must be a registered user to add a comment. If you've already registered, sign in. Otherwise, register and sign in.
| Subject | Likes |
|---|---|
| 5 Likes | |
| 2 Likes | |
| 2 Likes | |
| 2 Likes | |
| 1 Like |
