APIs are tremendously useful and are in use almost everywhere these days. But how do you make sure that attackers can’t abuse them? That’s the question Salt Security took up in 2016. We spoke with co-founder and CEO Roey Eliyahu and also received a demo of Salt’s platform.
APIs are getting a lot of attention from all sides these days. Developers use them to make applications suitable for integration into modern IT environments. Software vendors put a lot of emphasis on them when touting their solutions. However, attackers have also been paying more and more attention to APIs. This is because they are relatively easy to abuse, in part due to their highly accessible nature. Put somewhat bluntly, anyone can work with APIs.
The result of the popularity of APIs on the number of threats is quite significant. The general expectation is that it won’t be long before APIs are the primary route for attackers to enter organizations. Eliyahu goes a step further during our conversation by stating that all attack vectors will move towards APIs.
API-first strategy has consequences for security strategy
For organizations, the above trend is not good news. At least, if they still use the security tools that existed until recently. A Web Application Firewall (WAF), for example, is very suitable for securing legacy applications, but APIs are not part of that. Nor is an API Gateway suitable for keeping APIs secure. On top of that, APIs themselves cannot be made more secure than they are now. At least, not without violating their functionality.
Despite the above concerns, many (larger) organizations today have an API-first strategy. We recently referred to this in an article about how servitization causes fragmentation of the application landscape, where integrations between systems and software are crucial. These integrations mostly use APIs, either directly or via intermediate iPaaS environments.
However, an API-first strategy also involves a thorough evaluation of the dangers that the organization faces by deploying APIs. The result of such an evaluation, if done properly, is that the person in charge within the organization finds out that APIs are a significant security risk. In fact, this risk is only increasing. Eliyahu even goes so far as to say that all attack vectors will be going towards APIs in the future.
Obviously, Eliyahu is the founder and CEO of a company that specializes in stopping and detecting attacks on and through APIs and improving API security in general. So it makes sense for him to make such a statement. However, Salt is not the only one who sees it this way. Also at Gartner, they see 2022 as the year when APIs become the main attack vector.
Without Salt, no API security?
It should now hopefully be clear that it’s a good idea for organizations to take a closer look at API security. If so, Salt Security should be at the top of your list of vendors to contact, we conclude from Eliyahu’s words. “Before Salt, there was no API security,” he states. By his own account, he was convinced at a very young age of the vulnerability of APIs and the complexity of attacks that comes with them. “Attacks have evolved from one-and-done to low-and-slow,” he outlines part of this complexity. In addition, APIs are also often the only way to get in somewhere. He cites Zoom as an example: “Nobody has Zoom’s code, so you have to try to get in ‘under the radar’.” APIs are the way to go if you want to do that.
Salt Security is not the only player in this emerging market, but it does call itself the founder of the discipline. That seems to us a very valid claim, by the way. Eliyahu founded it together with Michael Nicosia in 2016. Until late 2018, early 2019, the company was in so-called stealth mode. That is, back then they were working behind the scenes on the product that would eventually launch the company out of stealth. Salt has since proven to be a success when it comes to market value. In late 2021, it reached unicorn status in an investment round. This means that the company is now worth more than a billion dollars. The most recent valuation is at $1.5 billion. About six months earlier, at the Series C investment round this was only 500 million. So things are moving pretty fast.
Not only Salt is gaining momentum in this part of the market, by the way. Noname Security, which was founded two years ago, also reported that it had achieved unicorn status at the end of 2021, albeit at a lower valuation of $1 billion. This indicates that API security as a whole is on the rise. This is a favorable development for this market in general.
Everything revolves around context
Salt Security’s API Protection Platform basically revolves around three components: discovery, prevention and remediation. The platform searches for (vulnerable) APIs and sensitive information in real time, has to stop attacks and has to improve the security of APIs in general.
To do this properly, it must first be possible to actually discover all APIs. That is quite a job, because every API is basically unique, so there are a lot of them, especially within larger organizations. That’s why Salt’s platform offers more than 50 integrations. There are integrations with API Gateways and load balancers, but also with Kubernetes and microservices.
All the information that is pulled into the platform in this way then goes into the platform’s so-called Big Data Engine. That’s basically where most of the magic happens. That’s where the AI in the platform adds context. A traditional approach with signatures will not cut it. Without context, you can never secure APIs properly. As an example, Eliyahu mentions an incorrect login attempt. Using the context in which this happens, you can determine whether it is a potential threat or not. Without context, you miss this.
Interestingly, the foundations of the Big Data Engine is not a secret. The patents are mentioned by name in the picture below. This image is also shown in this way on Salt’s website.
If we assume that Salt Security’s platform optimally secures organizations against threats related to the APIs it uses, then there is also always the issue of alerts. Within an organization, a vast number of APIs can be in use. You definitely don’t want to get a notification for every separate attack via an API. Then you would drown in it. “Too many alerts ultimately mean nothing,” Eliyahu summarizes the problem.
Salt says it has a solution to this problem. Its deep insights into the context of attacks and APIs again play a role here. This allows Salt to create a kind of fingerprint of the attacker. It is therefore not necessary to create a separate rule for each attack or attack type, something you have to do with WAFs. Salt’s platform actually doesn’t care about the type of attack, but in the attacker behind it. In this way, all notifications coming from the same attacker can be given as a single alerts. Obviously, that streamlines things greatly. In terms of order of magnitude, Eliyahu mentions during our conversation that this could be a single notification per 10,000 notifications.
99 percent out-of-the-box
Since we also like to know what something looks like in practice, in addition to the conversation with the CEO we also asked for and received a demo of Salt Security’s API Protection Platform. The first thing we noticed during the demo is that the interface looks very straightforward. This is mainly because of the limited number of submenus. It is immediately clear how things work in the interface. There is an overview of attackers (the fingerprints we talked about above), a Discovery tab and a Remediation tab. That’s pretty much it. Of course, you can click through and dig deeper and deeper into a specific API or a threat.
The API Inventory is a very interesting feature for users of the platform, especially at the beginning. From the moment the platform receives network traffic, it sees which APIs an organization is using. You don’t need to configure anything else about that. During the demo we were told that the platform finds 99 percent of all APIs this way out-of-the-box. Inbound, outbound and lateral APIs, the platform should be able to find them all. It does this by correlating endpoints with each other. An endpoint here can take many forms. This can be an appliance, but also a microservice, for example.
Salt Security’s platform, by the way, works agentless, out-of-band (so no disruption of “real” traffic) and can run in the cloud or on-premises. The underlying systems can be traditional, but the platform also runs in modern Kubernetes environments.
Attackers will have to get smarter
Focusing on the attacker rather than the specific attacks will result in fewer incoming alerts. We already mentioned that above. However, there is another advantage to this approach, we see during the demo. You tackle the abuse of APIs by attackers at the root. You block the attacker completely, no matter what he tries.
Blocking the attacker has two effects. First, it slows them down. At first, the attacker will not immediately understand what is going on. He will not see why he is not successful and he is blocked. Choosing another route or another type of attack makes no sense because his user ID is blocked. So he will have to find a new user ID first to make another attempt. In addition to slowing down, it should also ensure a marked decrease in the number of attacks.
Ready for the future?
At the end of our conversation with Eliyahu, we ask him how he sees the future. 2022 promises to be a busy year in terms of API security, that much is certain. He calls the fact that all attacks are slowly but surely moving towards APIs a ‘megatrend’. It is therefore important for organizations to look at this in time and take action. You can no longer have an API-first strategy without an API security strategy. At Salt Security, the internal focus for the coming period will therefore be on making the platform even better by investing even more in research. That will probably be necessary, because the other side is not sitting still either. In any case, 2022 will be an interesting year for API security.