Hi, I'm Tom Field, senior vice president of editorial with information security media group. My topic today is a fresh look at API security. It's my pleasure to be speaking with Roy, Iliyahu, CEO, with Salt Security. Roy, thanks so much for joining me today.
Thank you, Tom. Roy, before we get started, take just a moment to introduce yourself to our audience, please. So I'm Roy, Iliyahu, I'm co-founder and CEO of Salt Security, an API security company, and just as a quick background about myself, I was born and raised in Israel, constantly based out of Palo Alto, California. In my security background, coming from seven, four, a number of years, in the Israeli elite security units where I led development of cybersecurity products from a defensive perspective for the middle of the infrastructure and government infrastructure as well.
And also that's doing several security roles and really seeing how can API's becoming one of the loudest attack vectors to be full-founding salt. Well said. As you say, APIs are huge vectors these days. Digital platforms are increasingly a part of our lives.
We depend on them from work, entertainment, banking, to seem the doctor. For organizations that are a critical way to continue to connect with customers and drive revenue, what would you describe as the role that APIs now play in the digital platforms? Yeah, Tom, it's a great question because I think some people have a misconception about what is an API. And normally typically think about APIs as the nicely documented APIs you have for pulling certain data or when you integrate to Stripe.
The truth is that APIs are powering all the innovation in the world. If you think about mobile apps, our banking apps, you log into Amazon to order any products, you log into your email, anything that you do is through API, so mobile apps, web applications, you go to your laptop, and again, from a personal perspective, you have your own consumer products. But also, if you think about from a professional standpoint, when you go to your CLM, you have platforms or application that you can access as part of your work. You have also APIs to integrate to companies and pull information, right?
You have insurance companies or financial companies are exposing APIs for partners to pull into shared information. And that's only on the external facing side. If you think about the internal side of the company, we also saw a huge growth of APIs internally because you see how today we are breaking down the monolith application to microservices. So now you have a lot of external facing APIs to all those clients.
But also internally, you have a lot of microservices communicating with each other through APIs. So that's why we see to look at the graph of growth of APIs in the last two years. You can see an exponential growth because of all those reasons. And of course, I'll just add that all of our sensitive data going through those APIs, obviously if it's financial, if it's healthcare, seeing your doctor today, obviously remote, to your email, to your video processing, all of this data is accessible through APIs.
Roy, how would you say that API-based applications are different from traditional applications and what are the implications for security? Additional applications are built completely differently. So if you think about the evolution of applications, you start with the traditional applications. They were the website used to know that you have a client side was a desktop, right?
A browser and ask for a certain website. So what happens is that you have the server that ended all the data into a single HTML page that contains all the data and the browser would simply display it. It was very simple, very static, but then over time, we had more and more clients. Suddenly, we have smartphones, we have smart TVs, we have companies want to share information.
So instead of building multiple applications with the same functionality, you guys were invented to be the single source of data. So instead of having only one source, now you have or any one client that consumed HTML, in that case, how do you have API that any device unclimes an access? If it's a web, if it's a mobile, if it's an IoT, or if it's another company, want to pull the data without logging through an application, just pull them back to you. So that's the major difference between these two.
So Roy, Gartner sees API attacks on the rise and predicts them to be the top threat vector by 2022, and that could be a conservative estimate. How would you say the attackers have shifted their attention to APIs and what do the attacks look like today? Yes. And you know, Tom, I absolutely agree with this statement.
That's the reason why we found it solved, because if you think about what makes certain vector, a critical vector, a critical attacker, and what attackers focusing on. So you have one component is how valuable is the data, how valuable is the price, right? And second, that leads out easy to get the price, right? And if you have those two components, those two factors out high, so that would be the first vector that will attack.
And if you look at APIs, look at the facts, you know, if you guys want things, the most sensitive data that we have, all the financials, all of our data, you know, if it speaks to confidence all of our recording, audio, zoom, if it's a banking app, so all the financial data, if it's health care, it's all the health care data, it's e-commerce and so on. So you have very high, very sensitive data in APIs, and if you look at how easy it is, it's very easy because APIs are accessible to the internet. By definition, you know, they were built so different clients can pull information from. So for attackers, they don't need the internal access to the company to stop probing and looking for witnesses.
They can simply start and probing the APIs and look for witnesses if they find one of the pooling information out. And that's why you see high profile, which is like Facebook, like USPS, like Panetta Bread, like Google, that you see tens of millions of user records were leaked through API without the security team were aware of that just after the fact. Right. Talk to me about what you're seeing organizations do to protect their APIs.
What works? What doesn't work? So it's an interesting question because, you know, if you look at the type of the attacks are also completely changed, right? The attacks that were common five to 10 years ago are not common now for application in APIs.
Because of the uniqueness of every API, because you need an API for all the products versus transferring money in a banking app, it's completely different business case. Also, the logic behind the scenes are very different. So attackers shifted so that attacks look like more logic-based attacks, the target of the unique logic of APIs. And today, you know, companies are still being educated about how to properly protect their APIs.
Today, they are, you know, have their waft that, you know, that was there from the traditional web application time, and some of them have a guy management solution to expose API and to manage those. And definitely, you know, we see that is that all the attacks, the most common, the top attacks for APIs are simply go under the radar, even if you have a waft or API management, just because the way they built in their architecture, which is a proxy base, is not built and we're not designed to protect APIs. Roy, you mentioned API management. Of course, lots of organizations use API management solutions to have API security features, and yet we're still seeing high profile breaches in the headlines.
What's the disconnect? Yes, you know, we can think of why, you know, what's the function? What's the security? What are the security functions of API management?
There is three main security functions. One is encryption. You can have encryption. Today is also common, you know, adding those and load balancers as well.
One, second, then you have authentication, authorization, you can configure through an API management. And thirdly, you have like, you know, also manually configure. Now we can look at that task for APIs. All the attacks are more logic-based and API management since, you know, just to see how it was architected.
So if you think about API management as a proxy that sits in line, look at every request and do simple checks for it. If it goes about that legitimate, second, then it has the right key, right, the authentication base, all the documentation base equals one figure, and it takes the entire payload request, the entire parameters and just load them as it is to the back end. And most attacks lies in those parameters. So they're basically blind to these attacks.
And just to give you an analogy, just to make it a little bit more easier to understand, if you think about a company as a building and all the doors and windows are APIs. Now tomorrow you want to open a new door, a new entrance to the building. So you will use an API management to create the door. Maybe it will create the door.
It will even put the lock and it will give you a key and says, anyone that has the key can go in, right? So that's an API management. But it will not tell you when somebody is coming, try to break the door, right, come with the hammer, try to break the door and get in, you know, the lock will not allow you anything. It's not smart to lock, right?
It's simply a lock. So salt in that context will be the monitoring system that is more advanced, more smart, is actually using our architecture and our big data architecture, able to get to a very deep context to waste the unique logic of each API to know that something is anomalous or malicious specific API. And that's how it's more beyond verifying if somebody has the right key. I'm glad you mentioned your architecture, because I know it's salty, but a unique patent in architecture.
Talk a little bit more. Why is that important to API security and how does that make your solution different in this marketplace? Yes, that's an excellent question, because I think that's the key to understand how you can do proper or real solution for API security, because up until recently, it wasn't possible to develop an API security solution, a true one that actually protect against all the top 10 that OWAS is defined as the new top 10 for API security. But the reason why it wasn't possible, because as I mentioned, every API is very unique logic.
And if you look at the top 10 for an OWAS, and I'll emphasize that's the OWAS for API security, which was at least only this year for the first time, not the traditional web top 10 in OWAS. And if you look at those, you'll see every one of those attack characters are very targeted to the logic of the API. It means that a solution that needs to protect the API means also to have a very deep context to how the specific API is being accessed, and what is specific logic? Now, proxy-based solutions, like graph, like API gateways or anything that is proxy-based, is limited by the architecture to inspect calls on the fly, and to, you know, because it needs to have a very good performance, it cannot create a lot of latency, it can inspect the request for, you know, a few milliseconds and just passing forward, but it cannot analyze, because of this limited architecture, it cannot analyze, you know, hundreds of billions of API calls of every unique API to get a very deep context with API, and it also cannot correlate between different events having over time, because API attacks definitely low and slow in order to kind of assemble the big picture that is an attack, and this is a specific type of attack.
So in 2015, big data became more common, more mature technology that you can actually deploy in production, and we leverage this new technology with AI to get to a very deep context to learn in a very granular details, what is each and every API unique logic in order, first of all, to detect all the newer attacks, which is the majority of attacks today, but also to call it the dots, because APIs are not just one call or one specific attack, you need to call it multiple events over time from a single user to say, okay, this is an attack. So because we are not limited on a single machine as a proxy and we have the power of big data, we have the ability to track millions and years in parallel, and have a full context of all the actions coming from the same user to know this user is an actual attacker and then take an action and block them. Royce in closing thoughts, we have talked a lot about defenses and while stopping attacks is important, what else should people consider when building a strategy to protect their APIs? Yes, I think preventing or only detecting attacks for APIs is not sufficient because first of all, you need to know what to protect, right?
You cannot protect what you don't know. So the first thing I have here is to have a full API discovery. Now some people can have a very good discovery is a kind of generally cataloging one application to have. That is not the case.
Well, protection API is in terms of a very detailed, granular discovery that goes from the API host to the endpoints to the parameters, what's being sent on the payload of calls in the responses, get very deep in order to understand your entire attacks, without it, it's impossible to have the proper security reviews, it's possible to implement the right strategy. So first of all, you need to have a very general discovery, but also it's not static. It's not a snapshot in time. You cannot expect the communication to meet the discovery requirements because APIs tends to change more and more, you know, developers all the time become more agile, right?
You have more version being released to production and something that owned by dev and that actually works against security, right? You have more changes to more potential gaps. So you need to have a dynamic discovery, but in real time, when there is a new API and you change and sensitive that is being exposed, the security knows about it in real time and can prevent a breach that happened because of that, like we saw in many other incidents. And that's the first component.
Then you have the prevention force to detect all the attacks and to block attackers. But then you have an asked component that is missing, it's a limitation component because in APIs, it's a little bit different about how you will mediate compared to other security tools because normally security teams has the ownership to also to mediate, right? If you have a vulnerability and operation system, they can simply attach the system, right? They can do the fix and to remediate in the API case, they need the developers to remediate because they are not going to do any changes.
So they need to communicate to development where there are vulnerabilities and how they should fix them and you need to facilitate this communication in the most effective way because it's something that is agile and always you find more gaps in your APIs. So our last module installed, we have a mediation module that besides only blocking attackers is also communicating through geotechnics through, but geotechnics or any other ticketing system, what API vulnerabilities exist based on the attacks that occurred in production and allows everything to streamline it to developers so they can fix them and make sure the APIs has the best security posture. And just to kind of, you know, going back to my analogy earlier with the building and the door, the prevention, right, that discovery will help you to map all the doors and windows, all the interests of the company. And you'll be surprised how many doors and windows are unknown to companies today.
The prevention will help to detect if somebody is trying to break in and to try to create a hole in the door and go through the hole. But if you block the attacker and didn't fix the small hole that he opened in the door, it will come back in a different identity and will continue where he left. So the mediation module is the last module that will tell you in this specific door you have this specific crack that you need to fix and then you block and then you remediate so when the attacker come with a different identity and different account, it will all be being sealed. Roy, very well said.
I appreciate your time and insight today. Thanks so much. Thank you very much, John. Thank you for having me.
Again, we've been talking about a fresh look at API security. I've been speaking with Roy, Iliyahu, CEO of Salt Security. For information security media group, I'm Tom Field. Thank you very much.