Prioritizing API Security – Ori Bach, Salt Security
Ori Bach, newly appointed executive vice president for product at Salt Security, explains why the need to secure application programming interfaces (APIs) is becoming a more pressing cybersecurity problem.
Transcript
This is Textron tv. Hey guys. Thanks for the throne.
We're here with Ori Bach, newly appointed executive Vice president for product and SALT Security. And we're gonna be talking about all things a p i security. Ori, welcome to the show.
Thank you. Great to be here. I feel like sometimes a p i security is the redheaded stepchild.
Um, doesn't get enough attention. The developers think the security people are working on it. The security people think the developers are working on it and nobody winds up working on it.
So, are we getting better at all this and are we starting to realize that maybe this is the latest and greatest attack vector? Look, I actually think that a p i security is getting better. Uh, and I think we're experiencing a very natural cycle of innovation and risk management.
Uh, microservices architecture has really done amazing things. Uh, we're able to develop things faster and with better quality. And, uh, now we're realizing that attackers are using it to attack us faster and, uh, do more damage.
And we're putting controls and we're putting technology in order to manage that think a very natural cycle of, uh, innovation, uh, risk management, innovation, risk management. We're probably doing the same with Gen AI today. As we think through this whole process, it seems to me to your point with microservices, we have more APIs than ever, but are the bad guys getting better at finding those APIs?
'cause they know what to look for and they have scanning tools that make it pretty easy for them to figure out where they are. They are. And the, uh, the, the dark web ecosystem, uh, which is its own complex, and, uh, world is actually offering really good tools today on how to discover APIs, how to exploit APIs, how to conduct, uh, business logic attack against APIs.
Uh, so definitely, uh, from a risk perspective, uh, the risk is growing. I think most of the attacks today, I've actually talked to a number of CISOs, uh, in black hat where I am today, about 60% of attacks today involve APIs. And that number is growing.
I think the good thing is that there's more tools in order to deal with that, uh, which didn't necessarily exist a few years back. The irony of that is sometimes I feel like the bad guys have better discovery tools than the good guys. A lot of the good guys I talked to were, uh, still trying to figure out where all their rogue and zombie APIs are.
So maybe as the first step in this battle, just figuring out what is the attack surface we need to defend? You are exactly right. Uh, so on the one hand, uh, there's a tendency to talk about sophisticated attack vectors.
Uh, but if you kind of wanna look at the low hanging fruit, most of the customers we talk to, uh, ask us, just show me what I have my attack surface. And the minute that they see what they have, they find out that their APIs that they were not aware of. So even if they're not zombie right, they, they weren't even aware that this risk existed.
0, it's secure, it uses the best, uh, breed authentication, everything is great. 3, which is not been touched for two years is also out there. And that's exactly what attackers are looking for.
This is, like what you just mentioned, is a very specific attack vector, which attackers are constantly on the lookout for APIs that have not, uh, that are not being monitored, not being updated, and they can use, uh, in order to get data. I also feel like there's more types of APIs starting to show up. We're starting to see GraphQL.
There's a lot of these more arcane real-time APIs for all kinds of interesting applications. Do we really understand the landscape that we're trying to defend? 'cause I think everybody's a little maybe focused on rest, but not the rest.
It's a great question. Uh, and I think, again, part of the maturity, right? Uh, I actually, uh, think that security practitioners today, they are aware of the theoretical, uh, threats that are out there.
They are aware of the types of APIs, a lot more educated than they were before, mostly missing tools to allow them to manage that scale, right? Because look, security people are smart guys. They could do all of those things, but they're very busy people.
Uh, and it's all about the automation, right? So I think today we have good tools in order to answer the question, which APIs do I have? What is that they're meant to do?
What kind of sensitive data is flowing through them? And do I have the right controls in place in order to make sure, uh, that uh, they're not putting me at risk? A lot of people will make a case that says a p i security is a subset of application security.
Other folks are unique tools specifically for a p i security. What's your take on how should people think about that argument? Uh, I think, uh, both sides are right.
Uh, look, uh, the world is transforming from having like, uh, we've got, uh, desktop applications. So we've got, uh, different things that are on-prem and web. And ultimately for me, a few years we'll be talking about two things, applications and APIs, applications being, uh, ultimately the business, right?
So I'm trying to accomplish something by having an application out there and I wanna serve my customers. I wanna do something and how do I get that done? Uh, it's a combination of microservices and microservices.
Today are APIs. I think literally applications are today a set of, uh, smart APIs, uh, with some UI or no UI on top of them. So I think everybody's right.
I think, uh, application security is actually transforming to a p i security and a p i security is transforming to application security. We of course, hear about AI all the time. Do you think AI might level the playing field a little bit in favor of the cybersecurity folks?
'cause we know the bad guys are probably using it, but what can the good guys expect? I actually am a big believer, uh, and a big user of ai. And look, ultimately, uh, yes, there are very sophisticated attack vectors out there.
Uh, but 90% of problems are as humans, right? People that hardcode things, people that, uh, forget to authenticate people, uh, that, uh, forgot to remove, uh, an endpoint that's no longer needed. AI has a huge potential of actually getting us to secure coding practices because unlike humans, uh, once you teach an AI model what secure coding practices look like, and you constantly feed to it, oh, here's this new attack vector, you should do this, you should do that.
The great thing about AI that it is repetitive, it can scale out. Uh, so it doesn't matter, Hey, I've got a new developer on my team, uh, that might make a mistake if he's working with an AI tool. That AI tool will make sure that best practices are out there.
I am a big believer that this is going to change the fret landscape and allow us to, sorry, not the fret landscape. The, the actually our ability to be consistent, our ability to have good and secure coding practices, it is also an attack surface in itself, right? So something to think about, but in terms of what we are dealing with today, I think it is actually something very powerful, right?
As we kind of think this through longer term, um, do you think that, um, the number of APIs that we're trying to secure in production environments is significant? There's a lot of technical debt, so do we focus on those or do we draw a line in the sand and say everything from here on out, we're gonna secure, but, you know, and we hope that we'll replace those APIs someplace down the road and maybe like make them less usable by, uh, or more secure by replacing. Yeah.
Uh, look, as somebody that's within cybersecurity, I try to think not, uh, as, uh, somebody that's trying to be efficient at their job, I try to think as an attacker, and what would an attacker think about your statement? They would think, great, so I'm gonna attack those legacy APIs while you work hard to secure those new APIs. Uh, I think, uh, that there is a great opportunity, uh, to be able to secure all APIs legacy nuance, GraphQL, uh, and that is the ability to monitor for attacks against them in real time.
And the ability to mitigate that because it's a casual, right? It doesn't really matter how you wrote the a p i, what the a p I does. If you're able to identify, uh, malicious intent of somebody trying to use that A p i and machine learning and AI are very powerful tools in order to identify those things.
I think that provides a certain level of visibility, a certain level of control. So a hundred percent I would not recommend to just look at new things, uh, because the attackers are not gonna, uh, are not gonna be aligned with that strategy. All right.
So ultimately, what's your best advice to folks? I mean, you've been around the block a few times. What's that one thing you kind of see people doing that just makes you shake your head?
Uh, I would really encourage people before you make any big decisions before, uh, you invest, know what you have, right? And I think you just mentioned it. Know what attack surface it is that you're managing.
Know how that attack surface is actually being attacked. And this is not like a one-off, uh, every six months once we actually come into a customer, there are always attack attempts, not necessarily successful, but the attackers are constantly using automated tools. They're constantly probing things or trying to figure out things.
So just start with knowing what is your risk? What is your attack surface? And then make the best decision, uh, uh, that you can.
I sometimes p see people just committing into some kind of, uh, program, uh, going all in on, uh, very complex testing that's cumbersome for, uh, for engineering. And in fact, six months later, a year later, they find out that they were fixing the wrong problems. So first of all, know what you have.
I think that's the best practice. All right folks. Well, as always, you cannot defend what you don't know about.
Alright, thanks for being on the show. Thank you so much. All right.
And back to you guys in the studio.