One of the hottest trends in cybersecurity is API security and for a good reason. Security organisations have realised APIs are indeed everywhere: on any of their cloud environments and in their data centres.

APIs are used to communicate with customer interfaces, such as web and mobile apps, or to communicate with suppliers and business partners with server-to-server communication. Used for automation, used for administration – we can go as far as saying any piece of code that’s written in the last three years is either using or exposing an API.

This explosion of APIs comes with many challenges for the average security organisation. More often than not, APIs are being developed rapidly and mistakes are very common. Those mistakes can be design flaws, misconfigurations, and vulnerabilities such as inappropriate authorisation. It would be near impossible to find an organisation that is aware of all the APIs in its environment, especially the ones that aren’t routed through the centric gateway, let alone the data that goes through any of the APIs, or who is permitted to access the API or the data behind it.

How does that relate to Theranos? In case you aren’t familiar, Theranos was a ‘breakthrough’ technology company that claimed to have devised blood tests that required only very small amounts of blood, and could be performed very rapidly using small, automated devices the company had developed. The only problem? The device didn’t work properly and produced inaccurate results. Turns out the tiny sample of blood was ineffective, too.

In a very similar fashion, API security solutions are boasting their ‘breakthrough’ AI models, claiming businesses will never have to worry about APIs again. The problem is, just like Theranos, those companies are relying on a very narrow window into your environment. They only have limited visibility into API traffic without a contextual understanding of the API itself. In the absence of sufficient details and insights, API vulnerabilities can go unnoticed, and attacks can resemble legitimate behaviour. Just a few drops of ‘blood’ from an API traffic capture is simply not enough to build an accurate AI model for API security.

Noname Security recognises that the API security problem is complex and requires a unique approach and architecture. Therefore, we created a platform that, though sophisticated, is simple to use and is non-disruptive because it does not require changes to the network or architecture at the customers’ end. We provide value by solving the real issue of API Security.

But, how?

Poor API security solutions make empty promises, they bombard customers with buzzwords and obfuscate what’s really important. You can’t build an adequate API security operational model without sufficient visibility, context, and integrations. Here’s what’s crucial to know:

• Shadow, or Rogue APIs, are APIs you are not aware of. Often these are APIs that are not routed through a managed gateway. If your API security is reliant only on APIs routed through a gateway, it could result in serious security gaps that can leave these APIs exposed and vulnerable. Look for a solution that has multiple sources for API data, such as gateway integrations as well as network analysis. This will help to build a more accurate inventory of your APIs, including the ones you didn’t know you had.    
• API specification analysis can help with fortifying API security. Standards such as OpenAPI Specification (OAS) can streamline API design and collaboration. They can also be used to help generate code and ensure quality. Modern API security solutions can help you compare the written specification (OAS) against the actual observed traffic. Differences can be identified so that feedback can be provided back to the developers to remediate. This will help ensure the API is only used for its intended purposes and nothing more.
• It’s possible to detect attacks in real-time, address misconfigurations, and identify security defects for remediation. The challenge is doing it at scale and with operational efficiency.  API security solutions need to integrate and complement existing technologies such as WAFs and workflow tools. When attacks, anomalies, or misconfigurations are detected, the solutions should be capable of initiating the response. This could include automated (or semi-automated) signalling to the WAF to reset a session, revoking a credential at the gateway, or opening a JIRA change request to resolve a misconfiguration. The API security platform should leverage the investment in the technology stack you already have, not add more complexity.   

It’s noisy in the marketplace. You can feel spoiled for choice as you browse the shiny new software tools that could be the exact thing you’re looking for. But be wary – they could also be the wrong items, distorted by the vapourware fog.