Remediate – The Third Pillar in the API Security Strategy

Previously, I wrote about the Discover and Analyze pillars of the D.A.R.T. API Security Strategy. Discovery helps us understand what APIs we need to protect. Analysis tells us if and how they are protected (or not) and if they are being misused. If you haven’t read my earlier posts, be sure to check them out (linked above). Understanding the first two pillars of the D.A.R.T. strategy is crucial to getting the third pillar right.

Background

For many organizations, discovering and analyzing all the APIs is a monumental task. Using API catalogs, code repositories, and manual processes is time consuming and organizations never get a completely accurate representation of the APIs as they are deployed. The inaccuracies associated with discovery alone are myriad: documentation is incorrect or out-of-date; developers copy code from open sources then fail to incorporate it into the repository; the list goes on.

Analysis is also complex. If done correctly, it considers not only the API network traffic but also all the devices used to configure and manage APIs. If done correctly, it can identify and resolve all deployment issues, which dramatically reduces the application’s attack surface.

So, what happened to <fill in the blank with your favorite victim of an exploited API>? First, in virtually every attack, the API was deployed without using best practices for API security. Strong authentication wasn’t used; the application wasn’t protected by a web application firewall (WAF) or API gateway; or the API wasn’t tested for authorization attacks (e.g., credential stuffing, account takeover, and broken object level authorization also known as  BOLA). Proper analysis and testing could have, and in some cases might have, identified these vulnerabilities before they were exploited.

Remediate

If you detect an issue but fail to remediate it, you haven’t accomplished much.

The problem is, without the proper tools, remediation can be difficult, either because it is technically challenging or because it requires considerable time and effort. But if remediation is done right, it can often be automated or semi-automated and thereafter require little or no human interaction.

Your first step in remediation should be to integrate the Noname API Security Platform with your IT workflow management system (e.g., Jira, ServiceNow, or Slack). This will allow you to automatically assign issues to the appropriate teams as they are identified. Typically, the security team has few if any options for remediating API issues without help from IT, DevOps, the development team, or the business unit, so automatically assigning them to the right team significantly reduces the workload on the security team.

Say your company has a mobile app that resides in the /mobile subdomain. You would integrate Noname with your installation of ServiceNow. When the Platform identifies a new configuration issue within the mobile app (identified by the /mobile subdomain), a ticket is created and the appropriate product manager is immediately notified. The product manager can then assign the ticket to the appropriate developer, development team, or DevOps team. Depending on how severe the issue is, the fix can be scheduled for the next sprint or it can be handled by an emergency patch. If the product manager sees this kind of ticket regularly, logic can be added to send the ticket directly to the correct team (or team member) with a copy going to the product manager.

This should be the first level of remediation in any organization, and it takes just minutes to complete with Noname.

With semi-automated remediation, Noname is already integrated with existing infrastructure, whether it be the firewall, API gateway, identity provider, or some other device. The idea here is that a human must approve an action before it is taken. Say, for example, analysis reveals that an API is exposing too much data, but the API cannot automatically be blocked because its value to the business unit is unknown. With coordination from the business unit, semi-automated remediation can be used to temporarily block use of the API.

The process would look something like this:

1. Generate a ticket.
2. Contact the product manager and describe the issue.
3. Determine the API can be blocked without major impact to the business unit.
4. Activate blocking integration with the API gateway or WAF.
5. Leave the ticket open until the development team fixes the data exposure issue.

Over time, some issues are more likely to recur than others. These are the issues that should be considered for automated remediation. Take, for example, an API that does not have the appropriate security policy. The following simple steps can be completed automatically with the cooperation of the DevOps team:

1. Generate a ticket.
2. Notify the product manager and/or DevOps team.
3. Add the appropriate (e.g. OWASP) security policy to the API.
4. Close the ticket.

This issue can be resolved in seconds and with no interruption of service or risk to the business unit, leaving you with an API that is more secure and resistant to attack, effectively lowering your organization’s risk posture.

By proactively remediating issues as they are discovered, you protect your company, your applications, and your APIs long before the attacker can find the hole and exploit it.

All the issues I’ve discussed thus far can be considered “left of boom” in the timeline of the attack sequence, i.e., they are all identified well before they can be exploited by the adversary. But what about the moment of “boom,” or to the “right of boom”? Not every vulnerability can be addressed before someone attempts to exploit it.

Stopping the adversary in their tracks!

As an organization matures in its API security strategy, automated or semi-automated remediation can be used to stop the adversary from achieving their goals. Consider the following typical attack pattern based on documented white-hat hacker exploits.

First, target the application

1. Evade the WAF, if necessary
2. Discover an API endpoint (depends on the naming convention and patterns created by developers— is the API easily guessed? e.g., /application//user/api
   1. Is it worth exploiting? (Anything in the schema of value?)
      1. If yes, continue with b.
      2. If no, go back to step 2.
   2. Is the data real or tokenized?
   3. Is the API properly authenticated?
   4. Is authorization validated correctly? (If no, go to step 4.)
3. Script the exploitation of the unauthorized exposure.

The first step in the attack pattern is typically quite simple as the attacker can choose any mobile or web application. Often, the best choice is a recently updated application. This is because changes in the application (commonly referred to as “diffs”) often expose weaknesses in the old versions that are still active.

Once the top-level domain to the application is discovered, the adversary occasionally has to evade the WAF. Directory traversal will usually do the job.

Here is where things get a little tricky for the adversary. While some APIs are exposed by name through the application, this is rarely the case for all APIs. At this point, the adversary enumerates the APIs exposed by name and evaluates them as candidates to exploit. The adversary considers several factors:

• Is there anything of value?
• Is the data real or tokenized?
• Is the API using strong authentication?
• Is the data authorization validated?

If the enumerated APIs don’t produce the results the adversary is looking for, they will likely try to enumerate other possible candidates. For example, if an API is discovered with “/user/” in the URI, the adversary may look for “/user/details” and “/user/profile.” Educated guesswork takes time, but automated hacker tools speed up the process.

Once the adversary finds an API that can produce the result they want, they typically create a script to steal as much information as possible and in as short a time as possible.

The good news is that an adversary never needs to get that far. Let’s look at the attack pattern again, but this time, we’ll incorporate analysis and remediation.

1. Target the application.
2. Evade the WAF.
   • This is the first indicator of an attack that Noname will catch. Attempts to evade the WAF never look like normal calls to the API and consequently will expose the attacker, the user (assuming there was some form of authentication used), and the IP address of the source.
   • At this point, automated or semi-automated remediation techniques can be used to block the attacker at the firewall or the WAF, or to revoke their credential.
3. Discover the API endpoint.
   • The Noname API Security Platform will always identify the adversary when they attempt to discover the API endpoint. Assuming the product owner took the proactive, “left of boom” steps to ensure strong authentication is applied to APIs with valuable data, the malicious user (or adversary who compromised a legitimate user’s credentials) is identified by token and IP address.
   • The process of discovering valuable APIs requires making multiple unauthorized calls that should result in 404 or 403 errors. The Noname Platform generates issues on this anomalous activity, and the security team can then activate automated or semi-automated remediation to block the user as soon as their malicious behavior is detected. The adversary usually recognizes when they are blocked and refrains from making further attempts.
4. Script the exploit.
   • If the adversary makes it past step 3, it will likely take some time for them to finish writing a script to steal large amounts of data. And even if the script is completed before the remediation begins, repeated calls to the same API, or an API transmitting more information than normal to a single user will be identified by the Noname Platform as anomalous behavior. At this point, more automated or semi-automated responses can be activated to stop the attacker and mitigate future attacks.

Conclusion

While discovery and analysis must come before remediation, organizations that progress to automating remediations demonstrate a much more mature API security model. The Noname API Security Platform automates the discovery and analysis processes, and for the more mature organizations, delivers a platform from which they can complete automated and semi-automated remediations to block attackers and protect their most valuable assets.