Ten Things Your API Security Solution Must Do: Part II

In my previous blog, I talked about the need to strike a Shield Right While Shifting Left approach to protect your APIs while continuously discovering and tracking APIs while assessing and remediating risks associated with coding errors before they are published.

With the Shift Left while Shielding Right approach in mind, here are the remaining five criteria your API security solution must meet to ensure comprehensive API protection.

#6 Stop Automated Business Logic Abuse

Guideline
Look for an API security solution that can protect your APIs from all forms of automated business logic abuse. Common examples of business logic abuse include:

• The enumeration of repeated alpha-numeric fields in API calls.
• Adding extra parameters to API calls.
• Setting unsupported parameter values in API calls.
• Forcing APIs to return verbose errors and leak sensitive information.

Pick appropriate test cases to evaluate vendors’ ability to stop business logic abuse.

Importance
Attackers often use enumeration techniques to perform API reconnaissance, looking for potential targets. Once they find a potential business logic abuse target, new forms of automation are used to execute an account takeover attack (ATO) or fake account creation. Therefore, stopping business logic abuse early in the attack cycle is key to success.

Pitfalls to Avoid

• Avoid signature-based tools, like WAFs, that are easily bypassed by attackers.
• Avoid offerings that rely solely on sending signals to third-party systems such as WAFs. Such tools cause a time delay between detection and response, which leaves APIs vulnerable to compromise.

#7 Detect Automated Bot Attacks and Fraud

Guideline
APIs enable attackers to execute all the attacks listed in the OWASP top automated threats, often resulting in fraud and other business-related losses. Your API security solution must be able to detect signs of malicious automated intent hiding in plain sight by analyzing behavior in real-time using ML/AI.

Importance
Bot attacks directly impact an organization’s bottom line, resulting in fraud, increased infrastructure cost, poor customer experience, and inefficient marketing campaigns. APIs allow bots to send high volumes of requests that appear legitimate and pass most security controls, but as a group, they cause significant damage. You need an API security solution that prevents bots out-of-the-box with high efficacy rates.

Pitfalls to Avoid

• Steer away from first-generation bot mitigation solutions that require application changes and integrations to collect attack telemetry.
• Avoid API security upstarts that don’t have depth in their bot detection capabilities and don’t cover all types of bot attacks.

#8 Natively Mitigate Threats in Real-Time

Guideline
Select an API security solution that can natively detect AND mitigate threats without relying on any third-party solution integrations. The vendor should offer a variety of response options, including deception that is configurable by users based on APIs and threats detected. The solution should also support configurable automated responses for threats based on pre-defined policies to reduce administrative overhead and exposure time.

Importance
Native mitigation as compared to reliance on third-party solutions is critical for the following reasons:

• Native mitigation reduces the time window between threat detection and response. It should be possible to eliminate this time lag completely by having predefined threat policies and responses in your API security solution.
• The third-party solution response options may be limited to simple IP addresses and basic WAF rules, which attackers can easily bypass.
• Depending on the network architecture, the third-party solution may not see the same API traffic as your API Security solution, making it useless from a response point of view.
• The use of a third-party solution for mitigation creates dependencies and challenges with upgrades and vendor changes.

Having flexibility in your response options is critically important to your API security strategy. Simply blocking API requests is not always an ideal response as it may encourage attackers to try different methods and may not be feasible from a business point of view. For example, a business may detect a data governance issue with a business-critical API, so blocking access to that API may not be an option. Therefore, the API security solution must ensure the weakness is not exploited while also allowing legitimate API use during the time it takes the DevOps team to roll out a fix.

Pitfalls to Avoid

• Avoid tools that rely on third-party solutions like WAFs for their mitigation response.
• Stay away from tools with blocking as the only response option.
• Avoid deployment architectures where detection and mitigation components don’t see the same API traffic.

#9 Deliver Enterprise-Grade Performance, Availability, and Scale

Guideline
Make sure your API security solution can handle your business’s scale and performance requirements. If you are a large enterprise with many hosting environments, with many APIs generating large volumes of API transactions, the solution should scale with no impact on performance and availability. Establish a success criterion for scale and performance based on your current and future needs and develop a test suite that evaluates solutions against it. Your API security solution must be highly available (H/A) and support H/A as a deployment option. Test for fail-over scenarios with a H/A set up to ensure the solution does not fail open or fail close when experiencing downtime.

Importance
Often enterprises choose security solutions after a proof of concept that is limited in scale, and then the vendor struggles with performance and availability under full production load. This results in time lost and spent troubleshooting and re-deploying for both the enterprise and vendor. The result is a sub-optimal outcome from the decision, deployment delays, vulnerable APIs, performance impact on production APIs, and cost over-runs. Establishing clear performance and scale goals then testing against them before you select your API security solution can save a tremendous amount of time and money in the long run.

Pitfalls to Avoid

• Avoid testing API security solutions in small DevOps environments and not at a production scale or based on the future needs of your organization.
• Steer clear of vendors with no H/A support.

#10 Ensure Your Application Architecture and Data Residency/Privacy Requirements Are Supported

Guideline
Make sure you can deploy a vendor across all your API environments with a unified management portal across them. If not, these environments can be discovered by an API attack surface discovery tool mentioned in the first criteria. Additionally, ensure your API security solution integrates with your current and future choices in CDNs, API gateways, load balancers, service mesh architectures, and cloud providers. Regardless of your deployment choice, your API security solution must support data residency and data privacy requirements as well as regulations applicable in all the regions where your APIs are hosted. That may require support for SaaS, on-premises, and hybrid deployment options. Validate data residency and privacy compliance as part of your vendor evaluation. When applicable, ensure your API security vendor has appropriate industry certifications like PCI, SOC2, ISO, etc.

Importance
SaaS-based API Security solutions may send customer data to hosting environments located elsewhere for analytics. That hosting environment’s geolocation and certifications may compromise your data residency and data privacy compliance. Data residency and data privacy law violations can cost organizations millions in fines and prevent them from doing business in certain parts of the world.

Pitfalls to Avoid

• Avoid evaluating in a single environment type if your organization’s infrastructure is heterogeneous.
• Don’t take the vendors’ word for it regarding data residency and data privacy— validate claims with tests and documentation to ensure it meets all your needs.
• Avoid SaaS-only solutions where data residency and data privacy laws are strict.
• Avoid accidental exposure to GDPR fines by shipping PII data to a third-party cloud.

Conclusion

Organizations are rapidly adopting an API-first development methodology because of APIs’ power, flexibility, and efficiency. The shopping, finance, manufacturing, and marketing apps we use every day are all based on APIs, connecting back to compute resources located elsewhere — the cloud, the data center, or both. Unfortunately, threat actors love APIs for the same reasons that developers do. APIs are susceptible to a range of automated attacks and vulnerability exploits that can lead to data loss and system compromise. To protect existing and future APIs, organizations need to implement forward a looking API security solution that unifies runtime API visibility, security risk monitoring, and patented behavioral fingerprinting technology to consistently detect and protect against ever-evolving online attacks.

Get a FREE outside-in assessment of your API attack surface area – what an attacker’s view into your organization might be.