42CRUNCH BLOG


Why knowing is better than guessing for API Threat Protection


Why do we need different solutions for API Threat protection?

APIs are becoming a hot target for hackers. Analysts and cyber security specialists agree that the privileged position of APIs as the open doors to the enterprise kingdom make them a favorite to breach.

For the past 20 years, Web Application Firewalls (WAFs ) have dominated the Application Security market. Such products became a must if you wanted to achieve PCI-DSS compliance for example. How do firewalls work? Much like anti-viruses, they need signatures to recognize and block attacks. You need to constantly feed them rules, and having to manually design and deploy such rules has always been one of the main complaints against WAFs.

WAFs traditionally work with negative rules, built to recognize the traffic you want to block. It is technically possible to write positive rules of course, and as we explained in this post, while positive rules are universally recognized as more powerful, they are also much more difficult to maintain.

Fast forward 20 years and all applications are now based on APIs. What does that imply for WAFs? Nothing good.

In an article from Dark Reading dated July 2020, Ericka Chickowski mentioned that “organizations are particularly struggling as their current WAF deployments are unable to handle a broader range of application attacks, particularly client-side attacks, API-based attacks, and bot-driven attacks.”.

Why are APIs different?

APIs have totally changed our applications architectures, pushing business logic on the client side and removing the controller layer. Furthermore:

  • APIs are about transporting data and therefore protecting APIs is about protecting data.
  • APIs are just about everywhere – Frameworks and tools have made it very easy to create a API and expose in a matter of minutes. Security in this context is often an afterthought.

The OWASP API Security Top 10 illustrates the emergence of those new threats: data leakage, mass assignment, BOLA (broken resource access) РAll data related.

 

The promise of AI

So what is the promise of AI? You can continue to work the way you were working in the golden era of WAFs:

  • No involvement of developers in the security process
  • No early detection of potential vulnerabilities at runtime

AI solutions look at the production traffic and detect automatically abnormal behaviors. The promise is that you will be relieved of the burden to manage all those rules manually. Instead the AI engine refines its behavior over time, after being trained to recognize your API traffic.

So basically, we got smarter at guessing what the API traffic could be and even more, we now have tools helping us rebuild the controller layer checks that should never have disappeared from our applications to start with. In fact, we are now in a worse place: we build 1000’s of APIs at a staggering speed, don’t worry much about how they will be used and by who, and cross our fingers that a super smart engine is going to filter out the proper traffic from potential threats.

 

The power of knowing

With the 42Crunch platform, we take a completely different approach: we help enterprises engrain security in the API lifecycle as early as design time. To achieve this:

  • We equip developers with tools that allows them to detect and fix security issues early in the API lifecycle
  • We allow security teams to set compliance requirements that can be enforced automatically across hundreds of APIs
  • We provide a new type of firewall that understands the API traffic natively and uses a positive security model approach

Our platform leverages a de-facto industry standard for APIs, OpenAPI (aka Swagger). We built tools which integrate in the developer’s IDE and CI/CD pipelines to audit and test their API contracts and created a firewall that can be configured in one-click from the OpenAPI definition.

Leveraging developers knowledge

Security teams need developers’ help to understand and secure APIs. Developers cannot use the traditional tools security teams are using, they were not built for them. So how do we bridge that gap? By adding developer-friendly, security oriented tools to the developer’s tool-belt, for example our Visual Studio Code plugin which just reached over 100,000 users! Our Audit is integrated into the OpenAPI editor, giving developers instant visibility into the potential security gaps in their APIs and how to address them.

Putting APIs under control

Security teams are the guardians of the enterprise: it is their responsibility to ensure that the enterprise assets are duly protected and as such they must enforce some rules, rules such as mandatory OAuth usage, systematic validation of parameters against specific patterns, hardening of JSON schemas or JWT validation. Rather than discovering potential deviations via lengthy, manual testing when the APIs are ready for production, they can enforce those rules automatically at design and testing time.

More importantly, those rules can be enforced at scale across hundreds or thousands of APIs through automation via CI/CD plugins or our REST API.

Blocking unwanted traffic automatically

Once the API contract is defined, hardened and compliant to the requirements of the security teams, we can in one-click enforce protection. No need to learn, no need to train, no statistics to evaluate. If you declared a field accountID as a UUID, that’s what we will accept, and nothing else. We will stop anything unwanted on the first attempt, no need for runtime training, as all potential discrepancies were handled at development and testing time.

A positive security model also means:

  • No fishing around for info: hackers notoriously use calls to guess data or get access to what might not be documented. Not with us. If Starbucks had used our solution, they would have not made the news nor would have Equifax or Uber. All of these attacks could have been prevented with a hardened OpenAPI and our firewall in place.
  • Unwanted traffic like bots is also rejected. If you want to accept friendly bots, describe them and we will accept them. Otherwise, door is closed.

 

It’s not about technology, it’s about philosophy

We at 42Crunch have nothing against AI, far from it. But fundamentally, we believe that leveraging the developer’s knowledge and detecting potential issues early is much more reliable, cost effective and efficient than trying to guess which API traffic is valid after production. OpenAPI is supported by every API management solution on the market, and hundreds of tools are at your disposal to create, test, mock APIs thanks to OpenAPI.

So, let’s start by covering the basics: document our APIs and in the process, be ready to automatically protect them from potential threats.

42Crunch Platform and Free Tools

Contact us now for a free API Security Audit and Platform demo. Check out all our free IDE and CI/CD plugins to help you start securing your APIs today!