Enhancing AppSec: The Importance of API Security – Ory Segal, Palo Alto Networks

This is Textron tv. Hey guys, thanks for the throw. We're here with Ori Siegel, who's c t O for Prisma Cloud, for Palo Alto Networks, and we're talking about a p i security and sometimes the lack thereof.

Ori, welcome the show. Thank you. Thanks for having me, Mike.

A p i, security's become a much bigger point of discussion these days, but it's not clear to me that we're actually seeing attacks against APIs just yet, or a handful, or maybe there's been a small number that really stand out, so everybody's focused more on it. But what's your sense of what is the current state of a p i security? I, I actually, I think that's a misconception, uh, from what we are seeing and from the research of Thin published, um, through multiple resources in the past few years, uh, we're seeing dramatic increase in attacks against a p i endpoints.

Uh, um, you know, we should, we should consider these as application layer attacks or, uh, attacks against the applications, but via, uh, the a p I endpoints. And I think there is, uh, you know, there's a few obvious reasons for why attackers, uh, prefer to target these endpoints rather than go through the regular route of, you know, the web application or an F T P, et cetera. And that's because, um, these APIs are harder to monitor.

Uh, so in many cases, uh, organizations don't properly monitor and apply, you know, the right kind of logging and forensics for a p i, uh, applying a p i protection, uh, is, uh, more difficult than with traditional web applications. You know, you used to have, uh, we used to deploy web app firewalls in front of web apps, and those would take care of all the, you know, standard attacks, the, the scanning tools, SQL injection cross scripting. But when, when we're talking about a p i endpoints, you don't always know what you need to protect.

So attackers find these shadow APIs or those forgotten, obsolete stale APIs, debugging APIs that developers leave behind. Uh, a lot of the times we see developers, um, unintentionally overexpose APIs because they think that attackers don't necessarily know about them because they're not listed anywhere. It's not like, you know, if you want to go to a website, you go to WW and, and you know, you, you hit the website with APIs.

Sometimes these are the backend logic for mobile applications, for example. And so they assume that because you're using a mobile app, you don't necessarily know how and with what it is communicating. So it's sort of hidden in a sense.

Uh, but it's very easy to reverse engineer either the traffic by using proxies or, you know, uh, decompiling the, the, the binaries of the mobile application and then exposing those a p i endpoints. So they're not really that, uh, hidden or pure in a sense. Um, and protection logic is slightly different.

You need, um, a dedicated, not a dedicated solution, but a solution, uh, an application layer solution that understands a p i and a p i attack vectors. Uh, we're talking about slightly different message formats that are not, you know, always human readable, but, um, uh, so they are harder for a standard WAF to protect against. Uh, and even anti automation.

Uh, you know, a lot of modern web app firewalls would protect against attacks by blocking automated tools, which, you know, every attacker these days, uh, use. You, you don't always, or you, in most cases, you won't attack, you know, using your keyboard directly. You, you run automation scripts and tools like SQL Map, um, and scanners.

And with WAFs, we have anti, uh, bot protections. We can put a cap in front of it. We can put, uh, rate controls in front of it.

We can put all sorts of bots versus human challenges to protect. But with an a p I, um, that's not the case. You can't really use these protection mechanisms, uh, because we expect a p i traffic to usually be B two B or application to, to server side.

Uh, this is not human traffic, uh, and you can't put all sorts of challenges in the way, uh, because it's not a browser that's accessing them. So all of these reasons made APIs, um, uh, very appealing if you, if you will, to attackers. Um, and we see that almost in every kind of industry.

You know, if you look at the scalping and tickets and, and, uh, you know, the, the eBays of the world, um, um, automated tools that are, uh, trying to buy stuff in bulk and then sell it, uh, you know, on the dark web or something, um, there you would see a lot of, uh, bots attacking APIs directly because of the, the reasons I mentioned before. Uh, the same for financial websites, et cetera. Um, another reason for the increase, uh, I think in attacks is the fact that all new applications are developed with more modern, um, stack in mind.

So we are talking about cloud native Kubernetes, um, microservices and their a p i traffic is the new network. Uh, they all communicate between themselves, um, or the internals of our application, uh, is communicating using APIs. So that's the language that they're speaking, that's the protocol that's being used.

And so it, it only makes sense that that's how attackers will also, um, you know, try to abuse these types of applications. So it's more and more applications become cloud native, move to the cloud. We're looking at, uh, you know, a wide range of APIs getting exposed and, and that's a attack surface that's, uh, that's exposed.

Is in your sense that a p i security is an extension of app security, or do we need people who are specifically focused on a p i security? 'cause not everybody who built the app also built the A p I. So sometimes it's a different motion.

It's a great question. Uh, uh, in almost all conference talks that I gave in the last two years, that was, you know, the first thing I I say when I go on stage, I, I don't believe in, in the term a p i security. It's very misleading, and it's taking the focus away from the main problem.

Uh, and that is application security. The a p i is just a route or an endpoint or a way to interact with the application. Uh, the problems that we are seeing with a p i or the risks to APIs are risk to the application layer.

There are some nuances of how you expose the a p i do you expose it and, and enforce authentication and authorization at the a p I communication layer. Uh, but beyond that, you know, the vulnerabilities, our application layer vulnerabilities, if you look at the OAS top 10 for APIs, we, you know, Ebola and injection attacks. It, it's all going down directly to the application from the a p i.

It's, it's just the entry point, uh, in a sense to the application As we go along. Do you think that, uh, we also misjudge how sensitive an A P I can be? Because initially a lot of these APIs are internally facing, so everybody's like, well, it's behind a firewall, we'll be fine.

But then we discover that this a p i has been repurposed in some form or another, and it's suddenly externally facing, but we don't have any security around it. So are we kind of being a little naive about Yeah. What we think is the right level of security for APIs at any given moment?

Yeah, I, I, I totally agree with that. Uh, in fact, you know, some of these OAS top 10 kind of things, like I mentioned, bola or broken object level, uh, authorization, uh, are, are a direct result of that. We, we build the application, we build the backend logic, and then we expose it through a p i in a rather generic way because we want that a p i to be used by our own client, by third party clients, by, you know, B two B communication.

And so we want the a p I to be generic. We also expose, exposing in many cases, document, uh, full documentation of how to interact with the a p I. So there's no question about what kind of capabilities exist.

Um, how do I need to interact with a ai, there's no guesswork if, if you are exposing, let's say, an open a p i specification, um, if you follow the, that, that, you know, that standard. Um, and so we are essentially exposing business logic directly to the internet, uh, which brings the, or allows the attacker, uh, to get closer to the business logic in a more direct, uh, way. Uh, not, you know, not proxy in any way or, uh, so yes, we, we see, you know, some of the more interesting attacks that involved, um, malicious activities through a p i endpoints, um, involved access to business logic that should probably not have been accessed directly, but should have been mediated, uh, through some validation functions or, you know, a few other steps in the way.

Um, so yes, there is a tendency to expose sensitive business logic through APIs without doing the proper, uh, risk assessment or, uh, threat, uh, analysis beforehand. Are we getting better at allocating our security dollars properly? And I'm asking the question because security people wanna spend money on things that they control.

So they spend money on the network and the firewalls and all that stuff. And they think that somehow or other the developers are magically paying attention to application security. And of course, the developers think that the security people are paying attention to application security, and the end result is, we just don't pay enough attention to application security.

So are we getting better at kinda rebalancing where we allocate our limited cybersecurity resources? 'cause we still gotta protect everything at some point. Um, are we getting better?

Uh, that's a good question. Uh, if the answer was yes, we would see things improve over time. I, I've been in the industry more than 20 years, and things are very slowly improving.

I'm sure you're seeing the same thing, uh, not as fast as you'd expect or not as fast, uh, or not in sync with the amount of technologies, uh, for prevention we're spending. But I think there is a big, uh, there's a big change in recent years, uh, especially around consolidation. One of the problems with, uh, with security is that we keep getting defocused.

Uh, every time there's a new technology or a new layer in the stack, um, there is a new technology to, uh, protect and prevent risks in the, in, in that layer in that technology. You know, we've seen it with serverless security and container security, and then software composition analysis and dust and SaaS and waf. There's every time there's a new technology as a reaction to, to, uh, um, uh, a change in the paradigms of how we develop software and what are, what it is that we're using.

And, and those changes introduced, as I said, new tool categories and these tool categories defocus us from the main thing. And the main thing is we need to secure the application. We don't need to specifically concentrate on each and every layer.

We need to, um, we need to consolidate our effort. We need to be more effective at how we triage, detect, and triage issues. And so we are seeing this consolidation, and we are happy to be also a part of that trend of consolidating all of these security tools that have something in common or that give, uh, you know, allow you to do risk prevention at all layers at the same time, because they're all different aspects of the same problem.

Um, so I mentioned, you know, we talked about a p i security and container security and web app security and, um, um, source code analysis and infrastructure is code security. These are all different aspects of the same problem you're trying to solve, which is application security. When you had to use multiple, uh, separate tools requiring you to first of all have budget for many, many different tools, and then, you know, education around the tools, how do you use them?

How do you stitch together the results from these different tools? Um, then you get to a point where it's easier for you to triage. You can start saving time, you can start, uh, reducing costs and make things more effective.

So for example, you would have one platform that accompanies your entire, uh, or, you know, helps you through the entire application lifecycle from the moment you start writing code to scan the code to make sure that you're not introducing risks. Uh, then as you build the artifacts to make sure that you put guardrails around the artifact, so you don't need people to sit there and say, you know, to be the blockers. Uh, you know, you don't need security people, which are obviously understaffed all the time against the number of developers that you have.

Uh, so you have automation around, uh, guardrails in, uh, so you don't deploy artifacts to the cloud, and then you scan the environment and you get constant feedback whether new vulnerabilities are introduced, et cetera. So automation and consolidation are, uh, the, I think the biggest change that we are seeing, uh, in making our customers or the industry more successful and more effective and, and, uh, uh, yeah, more optimized to, uh, reducing the risks. What impact do you think AI will have on all of this?

Will AI save us from ourselves? Because it seems like part of the issue is we've made things so complex that it's easy for the bad guys to compromise. So ai, like any new technology, is a kind of a double-edged sword.

Um, you know, I, I'll give you the, uh, the negative side of it. Uh, so attackers use the same kind of ai. We, you know, we have multiple pro research projects going on in my, in my research team of how to use generative ai, for example, and LLMs and, and things like, uh, you know, G P T to craft automatically detect and craft malicious payloads, uh, you know, in order to abuse the system.

Uh, obviously as a proof of concept, not, uh, we're not about to sell this. Uh, so attackers, I'm pretty certain that attackers are doing the same thing. They are harnessing the power of, of ai.

It saves a lot of time, a lot less programming that you need to do manually. Uh, uh, just a couple of days ago I needed some, some kind of, for example, a Python script to interact and, and do some stuff on an a w s account remotely. It took 20 seconds to talk to Chad G p t and have it craft the Python program that I needed.

I didn't need to go and learn all the I A m permissions and all the ins and outs of the, uh, A A W S S D K for that matter. So I'm, I'm pretty certain, and we haven't seen attackers use that yet, but I'm pretty certain that they are doing the same thing and, and harnessing the power of AI for doing bad stuff. On the other hand, or the other side of the same, uh, you know, of the same, uh, technology, uh, is that we can use AI to again, uh, be more effective, optimize the processes, save time.

You know, we have, uh, in Palo Alto Networks as, uh, the X I A M, which is sort of an autonomous soc, so you can reduce the amount of soc uh, uh, people that you have, uh, that you know, that you need to have, uh, in every, um, uh, shift to handle, uh, the wide range of events. You can automate everything. Uh, AI has tremendous, um, possibilities and introduces a lot of, uh, possibilities to, uh, make things more effective, uh, reduce the amount of time it takes to, uh, mitigate security vulnerabilities and handle security incidents.

Um, there a lot of this work is very tedious and manual and, and requires, uh, you know, junior staff kind of thing, you know, SOC engineers and, uh, that are not necessarily, uh, the top security experts, but you need, you know, you need a lot of people to be able to scale and to be able to handle, um, a lot of incidents in real time. And so that can be, um, made more effective using ai. I tend to look around the a p I landscape, and besides seeing these rest APIs, I see GraphQL and all kinds of interesting asynchronous things that are being used for real time.

Is this gonna get harder before it gets easier? It seems like there's just a lot more types of APIs that we need to think about. Uh, it's already at the point that it's harder, unfortunately.

Um, you know, like any other technology, uh, getting everyone standardized, uh, that's not going to happen. So you have binary APIs using G R P C, which are super popular. Uh, you have, like you mentioned, you have your restful APIs, which are the standards, then you have GraphQL APIs, which are the new standard.

Um, and you know, you used to have X M L soap web services. We still see some of those here and there. Um, but yeah, in general, I think the one thing that's changed that nobody's afraid of binary protocols anymore.

And, and, uh, you know, with G R P C and some of the newer protocols and, uh, even HTTP three things went binary. And that makes things a little bit harder for the security experts to deal with. Uh, it requires a bit of tooling.

It's not as easy as reading clear text and, and looking at a p i requests and understanding instantly what you're seeing. Um, so yeah, the lack of standardization and the wide variety of different a p I message formats, uh, that's not, not helpful, but, you know, uh, it is what it is. That's how developers, uh, you know, they, they, they like the new technologies and they, they need to keep, uh, uh, up to date with it.

So ultimately, what's your best advice for folks? I mean, what should they be thinking about? How should they get started down the path of this and how do I wrap my arms around?

Um, so I already touched upon the, the issue of, uh, tool consolidation. I think that's, um, and again, I don't like using the term a p i security, but when you look at application and the a p i security specifically, uh, point solutions have the tendency to only concentrate on the A p I and that both drive, you know, defo you from, like I said, the main problem, uh, but also misses a lot of the, uh, other layers that are involved. And a p i is just an entry point to the application.

The a p i leaves, usually in a container in some kind of workload could be, you know, a virtual machine or a container, a serverless function. Um, and so it is affected by the vulnerabilities of the underlying layers. If, if the a p I itself is, you know, maybe has a medium risk vulnerability, but it lives and, and executes inside a workload that is misconfigured at the cloud account level and then has incorrect I a m permissions attached to it, that becomes a much more severe risk.

So looking just at the A p I layer, uh, is not something I would recommend. I would recommend, uh, looking at all of the different layers together and factoring in all of the risks when you try to assess your, uh, your, your, your own a p I risks. Um, so, you know, drop the, the point solution tools.

Go with a platform that provides you an end-to-end visibility to, to all of the layers of the application, including the, the a p I and, and its risks. Um, uh, that's one thing. The second thing is constantly monitoring, you know, know what it is that you're exposing that, that's, I think the first step in, in securing your application is knowing where it is that you're exposed, what is your attack surface APIs are, um, are quite different than what we're used to because, uh, today organization, uh, change code on a daily basis, um, you know, most of them change multiple, you know, push code commits, code changes multiple times a week and even multiple times a day.

And when that happens, the APIs change. Uh, new a p i versions are deployed. Older a p I versions hopefully, uh, get decommissioned.

Many times people forget them behind. So knowing what it is, the attack surface that you have, that's the, I think the most important, uh, thing to pay attention for, uh, pay attention to. Uh, and that can be achieved by observing traffic, observing logs, hopefully in an automated manner and not, not manually.

Um, I guess those are the, you know, the top two things I would, uh, I would consider. And of course, you know, we've been talking about shifting left, uh, security left, uh, for, for quite some time now, you know, several years. But start your a p i security testing and risk prevention as you code, uh, using static analysis, source composition, uh, software composition analysis, um, and, uh, put guardrails as part of your C I C D pipeline.

Uh, we are lucky, you know, we are fortunate enough, uh, that now the deployment process is, uh, is completely automated from code to cloud. Uh, it's all C I C D pipelines that are fully automated. It's very easy to bake security into the right, um, um, points in the lifecycle, uh, in, in the C I C D pipeline.

So use tools that allow you to integrate, uh, security into the C I C D pipeline and make sure that you automate these guardrails and that will save you a ton of time. And, uh, and the, a lot of headache. All right, folks, you heard it here.

We need a comprehensive approach to application security because, well, if you're not paying attention to it, the one thing for certain is the bad guys are. Hey, Ori, thanks for being on the show. My pleasure.

Thanks for having me. It's been great. All Right, back to you guys in the studio.