API MythBusters Crushing Five Security Myths that are Crushing Your Safety

Nick Rago is a field CTO and product strategist with Salt Security. This article by Nick discusses security myths related to APIs.

Attackers and hackers know two key security facts. These are –

• Security tools used today lack context. So, attackers take advantage of this. They look for application and business logic types of attacks.
• When organizations push APIs into production, only up to 30% of the permutations of the application logic are tested.

Myth 1 – My WAF (Web Application Firewall) does API security and prevents API attacks.

We hear from organizations that their WAF does API security and prevents API attacks. WAF cannot provide the required security, and neither can it prevent attacks. Preventing all types of attacks is difficult. You need to monitor and observe your APIs continuously and have the ability to catch and correct any mishap ASAP. The issue today is that every API endpoint has its own business and application logic associated with it. So, everyone will have a unique attack vector with a unique attack paradigm that an attacker will use. So, if we’re looking for signatures with our WAF or signature-based detection system, we could be missing all these attacks and key elements of attacks.

As hackers will also study all logic and put together a coordinated attack over months, you must study what the API consumer has done over timeframes to know of any untoward transaction.

Myth 2 – My IAM (Identity and Access Management Provider) and API Gateway protect my APIs.

If a hacker gets authenticated and is in, he can manipulate cookies to get data he should not have access to. As all the transactions are valid, that is, the authentication and the endpoint validation, neither IAM nor WAF will catch it. But, after changing cookies, the hacker can access data that he is not authorized to. If data is pilfered over a longish duration, no one will know unless it is closely observed over a period of time.

Myth 3 – Developers will build in API Security

We are demanding so much more from the developers today that they may not find the time to look at additional features. Developers are not going through security training. Unless we have specialists looking at security and adding in security as a specific role, assuming that security will be built in will not give you the required security. Facebook had an 18-month-long breach. A hacker figured out the collision of two microservices and used that to hack into accounts. The only reason the hacker got caught is they decided to turn up the dial enough that a blip appeared from an anomaly detection standpoint on Facebook. From a throughput or usage standpoint, that was the only reason this particular attacker got caught.

Myth 4 – We have a very mature DevSecOps pipeline already in place. 

In most organizations, three key elements are missing from application logic checks.

A lot of organizations are still not documenting APIs in the design phase. There are a lot of tools, including Salt, that can help you with documentation. A lot of analysis is done, but behaviorally, nothing in the pipelines today is flushing out possible hacking points. Salt has introduced a particular technology coming out this month. This AI-based technology studies your staging and performance testing environments to find how your API logic is put together. Salt also has an AI technology that plays the role of an attacker. It checks APIs to detect vulnerabilities inside your APIs.

The last piece is runtime protection. This is where Salt came from originally. You get immediate value there. No matter how great the pipeline is, you’ll not get 100% application logic permutation coverage manually, but this tool will catch everything for you. It gives you the ability to model things over long timeframes to flush out when you’re in production elements or nefarious API usage that you never thought an attacker would think of.

Myth 5 – I am sending my access logs to Splunk

Many organizations send a lot of data to Splunk. All this data cannot be analyzed in detail. Organizations do find 500 errors, 404 errors, or something similar. Behaviorally, there is not much context there. Looking at access logs will not give us details of what is in a request or a response payload. Splunk was not made for this. There are new tools, including some by Salt Security, specializing in this. Organizations should not just get alerts but should get context associated with it.

To conclude, you need technology like the one provided by Salt Security that will give you visibility to all the APIs out there. It will help you discover how they are used and structured, the type of data shared, and an analysis of the endpoints. It has the ability to understand how your APIs are supposed to be used and then report back with very mature AI and accuracy about nefarious usage. It has the technology to give you some posture information throughout the whole software development lifecycle, from the moment something is designed, giving feedback from a security posture standpoint to the moment it is actually deployed in production, and then funneling all that through back through the SDLC.