Over the years, the empire/new order has built three Death Stars – I know, one of them is called “Starkiller Base,” but let’s ignore the specifics for this post. Despite having arguably the best defense systems in the universe (multiverse?), all three were destroyed because of different vulnerabilities.
While we in the Resistance are super excited about that, several questions come to mind when you try to analyze what happened:
- Why didn’t the empire learn from its first Death Star failure and fix the vulnerabilities on the second and third Death Stars?
- Were security measures taken by the empire? If yes, why were they unable to stop the attacks?
- What could the empire have done to better protect the later Death Stars to win the war?
The details are pretty clear here. The thermal exhaust port used to destroy the first Death Star was not used on the second one. And the external shield system used on the second Death Star was not used on the third Death Star, so it would seem that the vulnerabilities were eliminated.
But we know the Rebel Alliance destroyed all the Death Stars. What went wrong?
The Empire Lacked an Adaptive Defense System
The empire was not able to protect its most valuable asset because it was not adapting to new types of attacks – instead, protecting only against known previous attacks.
Each Death Star was different. The Rebel Alliance had to perform reconnaissance to find a weakness they could exploit. Once they found that weakness, it became very hard for the empire to protect against an attack, because their defense systems were not adaptive.
Applying Death Star Learnings to API Security
The situation we have on our hands today with the growing use of APIs is extremely similar. Companies are developing APIs at an ever-growing pace, and every API is unique – within and across companies.
The fact that every API is unique makes it extremely difficult for traditional security solutions to protect against API attacks – because it means every attack has to be unique. WAFs and even more limited API security solutions have at least one of two major limitations:
- WAFs rely on signatures for threat detection, so they can only protect against attacks that happened before on other systems. They are unable to identify most API-specific problems such as business logic abuse and authorization exploits, which are unique and different for every API.
- WAFs and even most API security systems have another key limitation – insufficient context. Protecting millions of API calls requires a deep understanding of API behavior, across millions of users, to identify abnormalities and take action. To gain the context needed to accurately identify API attacks, API security solutions must apply cloud-scale big data as well as AI and ML. Because API attacks take days, weeks, or even months to unfold, you need rich context over time to distinguish attack traffic from normal traffic. Proxy-based systems such as WAFs obviously lack this level of rich context, but so do server-based or VM-based API security solutions – they simply cannot host, much less analyze, the dozens of terabytes of data needed to achieve this level of context.
The API Force is Strong with Salt Security
Many companies claim that they can protect APIs. However, only Salt Security, with its patented API security solution, can fully protect against the next generation of API attacks, as outlined by the OWASP API Security Top Ten. Salt leverages ML and AI to automatically and continuously identify and protect your APIs.
Salt understands that attacks constantly tune their efforts and has built an adaptive and dynamic solution to catching them, as well as addressing the other key aspects of protecting APIs, answering:
What is my attack surface?
How many APIs do I have? Where are they? Are they exposing PII? How do I keep my information updated as APIs change?
The Salt platform dynamically and continuously discovers and maps all of your APIs, across all of your application environments. It gives you full visibility with no need for an OAS or Swagger file, and it sees all APIs including those not in your gateways. It also identifies which APIs are exposing sensitive data, so you’re not accidentally revealing information you shouldn’t be.
How do I identify and block attackers?
The Salt platform applies cloud-scale big data as well as AI and ML to create a very granular understanding of your APIs and their behavior. This rich baseline makes it easy to identify anomalies, and you can set the platform to alert on such discoveries or to automatically block attackers. For example, if an attacker is trying to add another parameter “isAdmin=true” to an API call to elevate permissions, Salt will immediately identify this manipulation and take action.
How do I make sure I fix my vulnerabilities and harden my APIs?
Of course you don’t want to perpetually block exploits in runtime – wherever possible, you want to shift left and harden your APIs to improve your security posture. The Salt platform provides API design analysis, helping you identify security gaps even before you release APIs into production. Salt also uses runtime learnings – essentially using attackers as pen testers – to share remediation insights with developers. You can send tickets, which can be linked automatically to Jira or any other system, directly from the Salt platform, and they include data about the normal behavior of the API, the anomaly Salt found, and what the API should be updated to do differently. This context significantly shortens the time it takes developers to fix the problem and closes the loop between security and dev teams.
If The Empire Only Knew the Power of API Security
Imagine if the empire had this type of access to an industry-leading, patented security solution that applied AI and ML to automatically and continuously identify threats and attacks in run-time.
“Many of the truths that we cling to depend on our point of view.” –Obi-Wan Kenobi
Alas, the empire considered the Death Stars fully protected, yet they were not. Don’t make the same mistake as the empire. Learn how API attacks are evolving, how API security must adapt, and the context needed to fully protect your organization’s critical API-based data and services.
Contact Salt Security for a customized demo today. And May the Fourth be with you – today on Star Wars Day and every day.
*** This is a Security Bloggers Network syndicated blog from Salt Security blog authored by Ran Barth. Read the original post at: https://salt.security/blog/salt-security-the-api-force-is-strong-with-this-one