So, your API has been Breached, Now What?

Last week I had the privilege of presenting some real-world API security case studies at the annual API Summit in Austin, Texas. On foot of several requests, I have summarized in this post some of the key steps an enterprise should undertake, once they discover that their API has been compromised.

Dissecting the API Security Problem

The root cause of many API security breaches has been a common misconception made by security teams that existing investments in Web application firewalls and Static and Dynamic application testing solutions mean that their APIs are protected. Wrong! The traditional web application firewall (WAF) and security code testing solutions are not up to the task of finding the API vulnerabilities: 

• APIs require contextual awareness for effective detection and blocking, something that legacy WAFs are unable to deliver.
• SAST tools are designed to work with web applications constructed as for example Java Servlet HttpRequest.Bodypages or .Net ASP pages.
• Most DAST tools can’t provide an intelligent assessment of API security without a deeper understanding of the API endpoints.

APIs must not be treated like applications and are subject to a different range of attacks and vulnerabilities as identified by the OWASP API Top 10. Many of the breaches I examined were attributable to one of these Top 10 attacks, and many others besides. You can learn more about the minutiae of some of the more common OWASP API security risks in this recent webinar from 42Crunch. So an important starting point is to dissect what particular vulnerabilities you have been exposed to, in order that you can remediate against them.

OpenAPI Specification – Declare, Test and Scan

The fastest route to identifying the faults usually lies by consulting with the development team that built the API in order to analyze the associated OpenAPI Specification (OAS) or Swagger file that defines how the API should operate. Leveraging the declarative nature of the OAS file in combination with 42Crunch’s API-specific testing tools (API Audit – static testing of the API and API Scan – dynamic testing of the API) you can quickly assess the Data Validation and Security Conformance of the vulnerable API. 

Proof and Implement

Given that a standard WAF still isn’t optimized to protect APIs, 42Crunch developed API Protect, a purpose-built API micro-firewall that enforces in real-time the API security policy to protect your APIs. API Protect complements the testing tools from 42Crunch and can be used as part of the testing process to prove that changes implemented at design and development time will be effective prior to deployment. 

Once you have shored up the API by attaining a sufficiently high “security score” in the testing process, it is vital to ensure that the runtime implementation of your application retains that protection. API Protect is deployed from within the CI/CD pipeline and will automatically reconfigure every time updates are made to your spec. This gives peace of mind to security teams knowing that as the API specifications and security policies evolve over time, the underlying APIs and web applications will remain protected.

Conclusion

It is important to appreciate that an immediate plan of action must be implemented to ensure business continuity and that in parallel, a longer-term strategy should be adopted to prevent a recurrence of the damage and to protect the company’s overall API estate. 42Crunch has many demonstrable cases of intervening to generate immediate results but also is trusted by enterprises to implement a long-term API Security strategy. 

Key learning points

• Inadequate traditional security measures: Existing Web Application Firewalls (WAF) and application SAST and DAST tools are failing to counter specific API-related threat vectors. Legacy security measures will fail to detect vulnerabilities as they are not tailored for the application’s API-driven architecture.
• API attack requires an API-specific security solution: An API-specific micro-firewall provides a tailored solution to protect against API-specific threats at runtime. 
• Do not sacrifice security over user experience: Such an approach leaves applications exposed to deeper intrusions long before any breaches are detected.
• Automate and future-proof: The solution implemented must allow for ongoing automated improvements. The sheer volume of APIs in a digital enterprise requires a solution capable of automating protection to scale security without the constant need for manual intervention.
• Foster wider collaboration: The solution should not only address immediate vulnerabilities but also lay the groundwork for a security-focused development culture.