API Security During Holiday Season – Filip Verloy, Noname Security

This is Textron TV. Hey guys. Thanks for the throw.

We're here with Philip verlois is a technical evangelist for No, Name security and we're talking about API Security in advance of this holiday season, there will be lots of websites that are currently in the final stages are probably going up and in addition to new apis and pages and the question is as always are we thinking enough about API security or or some bad things about that happen Philip, welcome the show. Thanks, Mike. Thanks for the invite.

Looking forward to our chat. We've been doing this whole online holiday season thing for many years now and people have been building applications. And are we getting better at securing these environments and are we thinking through all the apis that we might be exposing?

Yeah, so it's our thesis that we are out of let's rise. We we started the company on the basis of we think of blind spot sort of in a security field when we talk about Traditional web services being sort of subsumed or replaced by API based applications be it from you know, mobile devices or people interacting through through a traditional website. These systems are becoming more and more complex and and are sort of distributed more and more as well might be even consumed from you know, different infrastructures partly on premises partly through the cloud and so on.

so it becomes really hard to fit those pieces together and really understand from a security perspective what the sort of end-to-end detect surface looks like So from a defender's perspective, it's becoming really hard to look at that holistically and provide sufficient. I would say security controls around there. Other bad guys looking for those apis because there's a school of thought that says they just basically go after the low-hanging fruit and it takes a little bit more skill the compromise and apis so what is the level of threat we're seeing?

Yeah, so in general, I do agree that attack. It's time to go for the let's say the path of least resistance for sure. However, if you look at sort of the tools that are available now to figure out how apis are powering certain applications and are sorting sort of powering mobile apps and so on that has become really easy as well.

So you can just open up your your Google Chrome developer tools essentially and figure out you know, which API and points are being called and then it's a matter of figuring out if you know some security controls are lacking certain things haven't been implemented correctly which unfortunately happens a lot and that becomes an easy entryway into those into those applications as well. There's even a Owasso then API security vulnerabilities list which sort of spills out all of the potential issues with apis and a lot of those X are fairly simple to be honest, so people not implementing authentication or authorization in a correct way opening up sort of their data externally think a good example was the recent Optus preach in Australia. For example, where basically an attacker could walk in and get about 10 million pii records from this customers.

So it's not that difficult once you really understand how apis work and you know, some some attackers like to go after those endpoints because the benefits really pay off as well potentially. Who's in charge of API security because it's kind of a derivative of application security and we've seen the constantly have that flowing back and forth between development teams and security teams and it just falls through the cracks. So are we starting to see anybody focus more on API security?

That's a great Point actually. So when we sort of look at I would say from a developer perspective people are sort of pushed to let's say to develop applications and develop functionality as quickly as possible from a business perspective. Because that's how you compete in the open market.

You need to sort of out out compete in terms of functionality and ease of use your competitors. So they're trying to get these applications into the into the open market as quickly as possible. So from that extent you could say the developers are responsible for developing secure apis in the first place again, if I refer to the OSB API top 10, if you try to as a developer avoid putting some of these let's say easy mistakes into production or let them Escape into the wild that's already a good starting point.

But of course once these apis are let's say in production and they're accessible over the network and now it becomes also an issue of you know, let's say more traditional security personnel and network security personal looking after those apis and trying to protect them. So the access to an API is typically safeguarded by a number of let's say inline security tools like your web application firewall or an API Gateway and those tools tend to be managed by more traditional security security staff. However, because of the of the way that API is really function on the backend.

I definitely would like to see it's a combination of you know developers making sure the apis are develop in a secure way and then once they're in production having correct security controls around them. So it's really a broad population. Unfortunately that's sort of responsible for securing apis, which sometimes leads to you know, people missing missing some controls and having some blind spots in the organization having some back and forth about who is ultimately responsible which then can we take in advantage of by malicious users.

So it's more of a team sport these days but there's the team kind of understand what's really at riskier because on the face of it. It sounds like you know, any an API is just another endpoint but in reality it's a data exfiltration system and you're starting to see bad guys pulling lots of data. And of course data is the most valuable thing in organization has so do we have the right level of risk assessment?

Yeah, yeah again a great point. So indeed the ultimate goal of especially the malicious malicious attack existing gets that data out of that endpoint and sort of figure out what they can do what they can do with the data that they can sort of gather. So most of the public breaches actually hear about are typically those types of attacks, right?

So so in retail we had like Target we at Home Depot and it's it's mostly about customer. I guess that get extracted through an API. So yeah, it's really about understanding the functionality that those apis extend by its nature.

I would say an API wants to be externally accessible because that's the only way a consumer can interact with it. So you sort of have to publish an API endpoint on the public internet, but then of course the application that's accessible through that API has certain functionality. The API sort of sits in between as a translation layer almost between the consumer and the application.

And where it oftentimes falls down in terms of security controls is sort of misunderstanding of that API layer in between and the functionality that It ultimately allows to be externalized. So it's typically about giving more access to you know, internal objects than initially was for scene during the design of the API and people figuring out how to then misuse that that logic to get to more data than than they were supposed to And an additional attributing fact that I I should say in terms of understanding and securing these apis that apis themselves also change, right? So we've gone from more traditional soap XML based apis in the 90s to now we see probably 80% of people are using restful apis.

But the rest apis have been around since 2000. There's Now sort of people starting to use things like graphql and grpc and the way these apis function are different from each other. So from a security perspective, it's really hard to keep up with that as well and to really understand between those different people types as well.

Oh, yeah that import but not an easy one to tackle. We're also seeing that there's a lot of different kinds of apis these days and it's getting more diverse. We see graphql starting to emerge alongside rest.

And of course, we had web services and all kinds of other stuff floating around. So is it just becoming more challenging this secure all these different types of apis? Yeah, absolutely.

So if you think about the way that apis have evolved so I think the comparison between the rest apis and graphql. Is it good one, for example, so with rest apis what you typically see is you have functionality that sits behind the certain endpoint. So there's a there's a host.

There's a method to get to an endpoint and then there's a part of that endpoint that provides a certain limited set of functionality. So in that way you could say it's rather static. So if you talk to endpoint ABCD, you would expect functionality of endpoint ABCD.

Now if you compare that with gravity, well, you have a single endpoint typically and you have a credit language. That's the ql and good off ql so you query the single and points and depending on the query that you write you get a certain piece of information or data back. So if you look at that from a security Active you still have this single connection.

You have no idea of predicting. What will eventually be credited across that single endpoint connection. So it's really difficult to then understand the data that's going back to the end user.

Let's say does that that he has to my security controls and am I supposed to allow and authenticated user to get to this data that is authentic is user has just credit or should be limited more somehow. So from a network security perspective. You can't put that control in place.

You have to put that control in place on the API and point itself and really develop security apis to make sure that and that's where you then Implement in this case sufficient role based access control as an example. We're also starting to see this transition to Cloud native applications. They're based on microservices.

Every microservice has its own API. Are we gonna scale out of control here beyond their ability to manage all these different apis much less secure. Yeah, so if you look at apis from a sort of 20,000 foot a few you do have application apis, which have typically the apis is Soviet most concerned of in terms of trying to secure those there's also infrastructure API see your point, of course, so we have a lot of micro Services if you look at things like kubernetes for example, and those systems provide typically infrastructure based apis that allow you to let's say configure and manipulate the backend infrastructure components.

And of course these systems then on top of them power apis application apis themselves. So you really have this building block of interconnected systems that you need to understand. So that's what makes it more difficult as well.

There are I think we are making Headway in sort of providing enough. Standardization that they're going forward that we can think about securing those modern microservices architectures a bit more as well. So we do have things like Ingress controllers protecting protecting those kubernetes infrastructure apis.

For example, we are looking at things like evpf to run Security Services in kernel in those types of environments as well. So we're making strides and making improvements there as well. It's just a matter of staying a couple of steps ahead of the malicious users automation.

So far hasn't been the case. Really. So what do you think that the average organization needs as sort of an early holiday present to get in front of all this stuff and because you know, there are a lot of things that are just about to be launched.

So what's that one thing you kind of wish everybody would pay a little more attention to yeah, I think one of the sort of truths in security I guess is you can't really protect what you don't know about and because of the sort of let's say opica this nature of apis. It's really hard to get a good sense of all of the apis out and get a full inventory of your exposure. So when we talk about apis we talk about things like zombie apis or Rogue apis and those are typically missed from a security perspective.

So starting with understanding the full API landscape that you're exposing externally is probably the most recommended first step And then of course, you'll also running your systems on on backend back-end infrastructure. So the idea is from a defense in that perspective. Make sure you have a secure backend infrastructure.

You have a full inventory of all of your apis and then you apply let's say your security controls around around the actual inventory and not what you think. You're sort of exposing external. All right, folks here first if you want to have a joyous and quiet holiday season go find those zombie apis before Halloween and kill them all ruthlessly.

Hey Philip. Thanks for being on the show. Thanks, Mike.

Appreciate it. All right back to you guys in the studio.