Securing Application Programming Interfaces – Gilad Gruber, Salt Security

This is texturong TV. Hey guys. Thanks to the throne.

We're here with gillig Gruber who's the senior vice president of engineering for salt securely newly appointed Skillet. Congratulations. Thank you.

We've been talking about API security forever and a day it seems like and yet it always comes across as kind of the red-headed stepchild of application security doesn't quite get enough attention enough focus. Is that changing from your perspective and if so, what's driving that I think one. Yes, it is changing and changing.

I think rather dramatically and I think the main driver of it is Basically, what we call application security is starting I think the fragment, you know, when we set application in the past you used to think of things, you know deployed somewhere installed somewhere God forbid, you know, write an installer and stuff like that. And what we're seeing today that things are becoming much more complicated. People are starting to understand that there are things that are their Core Business and they will their IP and they put their development efforts there and there are things that are absolutely necessary.

for their offering to work But that are not really their core offering so they can either Source them from another place. Or they don't even have the expertise to do them. I'll give you an example from my previous life, you know, one of the things we need to do it payoneer was authenticate users.

Do we want to be in the business of actually analyzing photos and doing liveness checks and trying to understand if you know a Nepalese driver license is fake or not. The answer is no so we wanted to partner with someone who actually does this really well. enter apis So you do all these things via apis also the the main drive and in modern architecture was started with with so a service-oriented architectures really evolved into let's write everything as a microservice in some cases in the extreme like, you know, Netflix with thousands and thousands of them but even companies that are not going that wild would microservices have many of them.

All of these things essentially change the Topography of of the surface of what an attacker would look at it's not just the the web interfaces that that are vulnerable or potential Ingress points for attacks. It's pretty much every single API that is either purposefully put on the public internet or inadvertently put on on something that's accessible from the outside that suddenly part of your attack surface. That's a major problem.

That's a major shift. I mean, I trust that you are aware of the fact that many companies are not even sure. What they're offering includes when they're talking about their apis.

I mean Discovery is an important part of API security, you know, just give me a list of what I actually have that's accessible from the outside and many companies are surprised when you present them with that list. See are you serious? I didn't know this even existed.

I didn't know this was still up and running I mean, One of the breaches in the recent years. I think it was JP Morgan or one of those Banks, you know, they they just forgot to upgrade just one API on one server to 2fa and they got breached to that tiny little hole that everybody forgot about on a machine that probably nobody looked at for years. So yeah, I think that the Threat profile is is evolving because the applications are becoming much more complex much more interconnected between one another and between themselves to themselves and that opens just a whole new universe of things that you need to worry about and take care of it.

Do you think the Cyber criminals are discovering that because it looks to me like one of the things that makes apis attractive from their perspective at least is I can exhale trade data and data is what they're after. Yeah, I'm sure it's attractive because you know some of the things that we're seeing as people are trying to get their hands on on other users' data. So some of the attacks that we're seeing, you know are our credential stuffing to try and and move from one user to the other or attacks that try and you know shift somehow the request so, you know, I logged in is gilad, but you know, maybe I'm trying to get Mike's data because either I'm guessing his ID or trying to make sure I mean trying to verify if the back in system is smart enough to understand that if the cookie says Guillard and some idea on the request says something else that that's not a valid request.

So the attacks are getting very very sophisticated. And people are going both after the data and after in some cases even trying to perform transactions. Who is in charge of securing these endpoints essentially because they are a new type of endpoint but we hear a lot about shifting left these days and we hear a lot about that application development teams taking over security responsibility.

And then of course, there's the traditional cybersecurity team and among that said who's in charge of what? So that's actually an interesting question. You know, there's a there's an old adage that says that you know, however earlier at the life cycle of the development you find something the cost is is reduced by 10.

So finding it in in production is is X finding it in in sandboxes x divided by 10 and so on and so forth. So obviously anything you can find and development would be much easier to fix introduce less risk to the system. And that means that the responsibility if you assume that the development team now owns security is is much reduced and is a theory easier to fix in actuality if you look at the workloads that most development teams have Are that's really hard, you know, you have the product management and the Strategic roadmap of most companies pushing in One Direction.

And then you have either the csos or the chief security officers or even scanning tools like shift left or code scanners like sonar Cube or any number of tools in that order basically producing endless lists of things that need to be taken care of any of them by the way false positives, which makes it even harder to identify. What's really a security issue or potential issue and what's not so they actually the responsibility is probably divided which makes this problem even harder to solve which is one of the reasons that that we assault start from the from the right and not from the left. Because we think that it's a very hard problem not only to find all these things and development although everything you find there and fixes useful, but it's going to be hard to schedule these tasks into the development team and it's going to be even harder to understand that a critical as reported by one of these tools might not actually be critical because of other things in your network setup.

So if you have a really good perimeter defense, maybe you can afford to not handle immediately some of the criticals or highest that are found by these tools so actually going by what is exposed and usage patterns and looking at how things are actually behaving we think is a much more fruitful approach in trying to address the real threat that that you're facing about but it's they're all valid approaches varying degrees of work and some of them put more effort on development in some of them less and that's just an additional thing that needs to be managed very carefully and is a huge conflict within the development workstream. A lot of times folks will say well that's internal facing and therefore we don't have to be as concerned about it. But it seems to me these days a lot of internal facing apis suddenly become external facing and people don't really think through the security issues that go with that so, Do we are we kidding ourselves when we kind of try to distinguish between internal and external facing apis?

I think we are I think that's why discover is such an important part of the process. And again, we keep surprising people not just us other companies who are doing similar things with did you know that this is the list of things you're actually exposing to the world and usually they look at it in shock and say no are worse than that in many cases the mistake required to actually convert an internal API to something that's visible from the outside. It's not that great.

It's sort of you know, something that that can really happen. So it's not even not thinking about security just making an honest mistake. And and if the thing is too complex or too easy to make that mistake, then that mistake will happen.

They will have a probability significantly greater than zero of it occurring. And in that case you will have internal apis that are exposed outward. And can be used or exploited and they probably were not designed to be externally facing apis probably don't have all the monitoring and the authentication and authorization capabilities built on top of them to harden them.

And suddenly you have a problem that you completely didn't foresee. And the apis are proliferating at a rate that just unbelievable. Not just the external ones.

The internal ones are so yeah, you have a real we have a real problem there as an industry in my mind. Of course, one of the more popular television shows at the moment involves zombies and we have a thing called Zombie apis from your perspective. How big of a problem are all these zombie apis.

Oh, they're a real problem. I had I had a few of my own in in some of my past companies and it was not a pleasant surprise to find one of those guys, you know, lurching around and causing problems. How do you go about discovering those apis and all the apis in general and my scanning for them or is there some other way to do that?

And how do I keep track of them as they're created? Because the whole environment is pretty Dynamic and in fact, the people bill in the apps may not even be the same people building the apis. Oh, yeah, that's true.

I think it's it's very interesting trying to rely, you know on on good governance and good faith and and you know having the right definitions and having the right processes and all those things is good. Do I believe in the real world that that would actually get you covered to a very large extent? Probably not.

So yeah actually have to look at the traffic from passing in and out and through the network in various places, you know laughs and and API gateways and various other things that that we look at in order to actually see what is really there in talking to each other and talking to the outside world and make a list of that. I think that's a much more fruitful approach plus when things go online. They're discovered as an anomaly fairly quickly.

So even if somebody didn't remember to report, you know to the API committee or the API governing body or whatever at least you have somebody there standing watch and looking what's going around and what's floating around on the network to actually report that to someone and I think that's that's one of the key things again mistakes will be made it's so complicated in so many development teams are working on so many things at the same time that really trying to control this. Are the process? Is a good effort it's worth doing.

It's not going to get you there. We have so many different types of apis these days. I mean it used to be relatively simple.

They were rest apis and made me some Legacy stuff before that. And now we have graphql and all kinds of stuff coming around the pike. Is you got to look at all of those?

I know is it over? Is it becoming too overwhelming for us to keep track of all of this stuff? I think you know, you will probably see that we call this around specific types of apis.

I mean we used to have soap in the past and that was all the rage at one point in time and then it went away because it actually wasn't that great. It was too worthy. It was too slow.

It was hard to do specific things with it. So I think that you know, there will be different flavors because they serve different purposes. But I don't think that number is going to grow without bound.

So yeah, we'll have to deal with you know, various forms of apis and various communication protocols that carry them. And that will be part of the technical complexity that we all have to chart and navigate. You can now walk down the street today without somebody jumping out and explaining to you.

How AI is going to transform this that or the other does a I have a role to play in helping us with API security. Oh, yeah. I mean just consider simple things like, you know, I I called My I don't know reset password API a few times.

So, you know, yeah, I'm sort of a class and I don't quite remember my password. So, you know oftentimes on sites that I rarely visit I have to do that two or three times until I get it, right. But API about AI can help you identify things like, you know, usually somebody or user from a particular location.

Let's say in the world or particular IP or things of that nature approaches that API or calls that API a certain number of times a day when you start seeing really strange anomalies and when you start seeing, you know, maybe additional parameters throwing into the requests or or repeated, you know things that do things in sequence trying to activate apis like the reset password. That's where API can shine because then actually can look and sift through a large amount of data and try and find the anomalies in a way that a human be very hard pressed to sift through all the noise. Right.

What's your best advice to folks? What's that one thing you see over and over again. That just makes you shake your head and go guys.

We're better than this. Oh God the mistakes. We all make is developers.

Yeah, we want to get it to production. Yeah, we of course need to document this. Yeah, we will check that that the code in there actually knows how to handle, you know, formula injection and SQL injection and code injection and God knows what else And oftentimes, you know, we either forget or we don't do it all the way through and and you know, I think that the the thing is that the advantage is is with the attacker we have to defend everywhere.

in order to succeed they have to succeed in just one place to succeed. So I think it's good. It's it's a very difficult battle and I think the more tools the more AI the more sophistication goes into understanding what attacks look like and what vectors are being used to actually perform.

These attacks is really key to being successful and protecting yourself and you know an interesting challenging time. All right folks here in here. It's all about Behavior either of the developers or the apis.

But one way or another we got to figure out how to or the crooks or the crooks. Dylan thanks for being on the show. You're appreciated and thanks for having me.

All right back to you guys in the studio.