Protecting the Web App and API Attack Surface with ThreatX’s Jeremy Ventura

This is Textron tv. I have the great pleasure of being joined by Jeremy Ventura. Jeremy is ThreadX Fields cso.

Welcome, Jeremy. Good to be talking with you. Thanks, Mitch.

Thanks for having me on today. Look forward to the conversation. Me Too.

We're talking about APIs and security. Lots of great things. Before we do that, just tell folks a little bit about yourself.

Also tell 'em a little bit about ThreadX. Okay. Absolutely.

So as you mentioned, name is Jeremy Ventura. I've been with, uh, ThreadX now for just about a year and a half, but I am, uh, currently the field ciso. Um, so I'm responsible for thought leadership, uh, meeting with our customers and prospects at a senior level executive, uh, reach from CISOs to CIOs and really being a trusted advisor, a consultant in many different times and days, and, uh, making sure that our customers are always happy with our products.

And, you know, always having a forward looking thought process of, you know, where's this market going? How can us as threat X as a company always, uh, provide better services? Um, but a little bit about ThreadX.

Uh, we've been around actually coming up on a decade now, uh, started in 2014. We are a managed API and application security company, and we provide a solution for our customers and prospects around the world. Uh, that helps 'em really protect against some of the API threats we've seen out there, like credential stuffing, SQL injection, but also really looking at it from a botnet perspective, DDoS protection, um, and even now, uh, with recent news into our newest, uh, featuring capability in runtime protection.

So really getting a comprehensive visibility and view into your APIs and applications And, uh, given the landscape of applications, architectures, cloud native, but even just, you know, edge applications, you know, the, the attack surfaces, I think wider and deeper. I mean, the surface is just going in all directions and it's tough to keep track of it. So you've gotta have somebody you can work with that can move with you and also move with the attack surface.

Absolutely. Definitely. And I think, you know, that's one of the things we hear all the time is just how that attack surface is ever expanding, even from the back in the days of, uh, it feels like covid was, uh, so long ago.

But really, you know, 2020 coming up on three, four years ago where we moved organizations moved to this, you know, hybrid workforce. So this digital transformation as they coined it and we saw applications move to the cloud, we've seen APIs being more, um, leveraged by developers and engineers. And so that to your point, has just really, you know, increased usage means increased risk for a lot of these organizations as well.

So that's kind of why we're in business today. Excellent. Well, well let's talk about parts of that.

Um, attack service. Obviously people are going multi-cloud, they're also pushing applications to the edge in many cases, even onto devices that may not be fully connected all the time, whether it be cars or, uh, platforms like that. But, you know, the edge has become a big part of it.

Of course, APIs, you know, used to be sort of the crunchy hard surface to get in and out of of applications. Now API is the application and, you know, sometimes it's not even clear when things are going inside or out. So talk, talk to us a little bit about the kind of concerns customers come to you about.

Yeah. Um, so, uh, you know, ThreadX and kind of where we've played traditionally has always been at layer seven, uh, which for those who, uh, are not familiar with is the application layer, uh, and the OSI model. So, um, we're looking at H-G-T-P-S traffic, so looking at that, what we call ingress traffic.

So what is actually hitting your application from a public facing external perspective? Um, what is happening to that application? Is it, um, somebody trying to do damage to your website or is it somebody that's trying to infiltrate maybe a development application that hasn't yet released to production?

And so we've always played in that space. And so customers traditionally will come to us and say, you know, we've been hit with things like I mentioned before, but credential stuffing, especially when we think about credit unions, financial institutions, um, think about username and passwords. If I can get into your banking account or your banking login website, um, I can do a lot of damage, right?

Whether it's stealing funds or causing damage to yourself. And so we've seen a lot of different approaches and needs for ThreadX from the aspect of looking at some of that, what we call the oass top 10 mm-hmm. Um, which, you know, is a lot of those different types of attacks we've talked about.

Um, programmatic axis, SQL injection, um, even going back to, you know, we've seen a lot of this, especially in the last 12 months here with DDoS attacks. Um, so again, stating at the application layer of, you know, is my website or my applications being pounded by botnets, for example, trying to deface, um, my website, uh, for whatever the purpose might be, whether it's political, whether it's financial, whether it's a reputational damage. Um, so we've seen that traditionally, and that's kind of where the space we played in.

But where we've seen this progression, and I think you can look at this just in the space in general, is we've seen applications and then it's kind of to your point, it it's kind of moved to, well, how do applications communicate? How do they talk via API? And we think about the APIs in general.

A lot of these APIs hold a lot of data that could be sensitive data, that could be data PII data that could be even credit card information, uh, PCI data for example. And so depending on your organization, depending on the business you are in, those APIs are really what I like to call the connected tissue of how really you're driving revenue, you're driving operations, especially if you have applications that can go and integrate with other solutions or you want to integrate with other service providers out there. Typically those connections have made via API, those, API is really the glue.

And so protecting them, getting visibility into that is super, super vital and important for organizations. So that's a lot of it where organizations say, we know you're use, we're using APIs and applications. We don't know how many we have.

We don't know if they're being attacked unless it's something serious. Um, and then how do we go and protect that? And so that's a lot of the challenges that we are helping solve for our customers.

Yeah, I like how you've evolved, you know, with the times of course, but you know, being kinda web application security, and then you kind of, I, I think on your website I saw and APIs because that is the, the connective tissue, right, of applications, whether it's our own or two third party services. I assume you're talking about restful calls, right? Over h TT P that you're looking at.

Um, talk, talk about. So how do you protect that? Do you do anything different for, for APIs versus normal HTTP traffic?

Yeah, so, uh, I think our kind of, um, sticking point or kind of what makes us different in the market, um, is a lot of vendors traditionally have been focused on what we call the shift left side. So really incorporating security part of your build process. So incorporating that in your CICD or your SDLC software development lifecycle.

So really how does security become a test or a hook into that pipeline? So you're protecting your applications, your code before it actually pushes to production. And, um, I will, I will say, right, take my vendor half off vendor hat off.

That's super, super important. Where we play is a little bit more on the right hand side, which is actually looking at real time or runtime protection. And so that is where we found kind of our bread and butter is our sticking point is, while it's great to incorporate the security provisionings and checks part of development, you also need to protect what's actually in production.

So what is my website doing? What are the actual calls that are being run? What happens when I execute a command and now a container or a node is spun up and now the application's running, for example?

And so our kind of, um, unique and kind of secret sauce here is we don't look at it from a signature standpoint. And that's a lot of the traditional legacy tools out there, uh, especially in the web application firewall where they're looking based upon patterns of what they know is to be good or bad. And as we know, attackers are way more sophisticated now than ever.

Um, they're using IP addresses and other different types of attributions and characteristics to evade detection and legacy solutions aren't keeping up. So our kind of unique sauce here is we're looking at this from a behavioral, uh, signature standpoint. So what that means is really correlating massive amounts of data to say, this is who, what, when, why, and this is how they're doing it.

So really correlating it back to what we call a threat actor or a threat entity. And then watching that pattern over time based upon all that data that we can analyze sitting at that layer server from that HETP, um, H-E-T-P-S level. Now, where that's also gone though, and kind of some of the new exciting things that threat X has, uh, just announced a couple months ago and we're about to go GA now is with our runtime protection.

So really adding another functionality and capability, really it's another deployment method. So instead of looking at H-E-T-P-S and kind of that as a reverse proxy, we're now allowing organizations to deploy, um, kind of at the kernel level. Uh, it's leveraging a technology called EVPF, extended Berkeley packet filtering.

Uh, and traditionally we've seen a lot of EDR endpoint detection response products and companies leverage this, but we're using this and this is gonna allow us to look at the actual nester or the code. Um, so looking at it, uh, from the actual kernel level to see, you know, what is the network monitoring, what are the system calls? Are there any OS level protections or commands that are being run?

And the perfect example of that, which we've seen, which caused massive headaches for organizations in the years past still today, is log for J, everyone remembers Log for J. And when that happened and all the different variants of, uh, vulnerabilities and exploits, that kind of spun off that and a lot of organizations didn't know what, where it was, do I even, am I running log for j? Am I running this library?

Um, is it running in production? Is it in a development? And so this runtime solution, uh, presented by ThreadX is really gonna help organizations when it comes to a lot of the things we talked about, like zero days east, west traffic, insider threat again.

'cause it's looking at kernel level and kind of that os level protection. Yeah, it, it's, uh, interesting to see it evolve back to the lineage kernel level. I remember doing some work early on in vulnerability and intrusion inspection, and a lot of the issue was just handling the traffic load of trying to be that gateway or that firewall or whatever it might've been.

And, uh, by operating at the kernel level, you reduce the number of system calls. You're seeing things as they, as they happen, not as they're transmitted. Right.

So you're not working at wire speed, you're working at computer speed. Exactly. Yep.

I also like to, uh, kind of use the analogy of, uh, if you think about it almost like a house traditionally where the, the world is played, including FedEx and our products and services is really the perimeter, the edge of the house. So whether that means you're putting up a fence or you might have a security guard outside if you're really rich or famous, um, but it's protecting you from the outside of intruders trying to come in. But what we've always kind of just lacked in visibility and protection in the industry in general was what happens if an attacker was already inside or what happens if you have an insider threat, maybe it's a disgruntled engineer that's, you know, unfortunately getting laid off and they decide to put malicious malware in a in a new product that is gonna be delivered and that individual leaves and three weeks later when the new, uh, coders or developers are ready to push that to prediction, they click execute and there's malware now spun off right from an insider threat.

So this is really taking a look, not just at the, the fence and the perimeter, but also imagine having the security cameras and a and a bouncer walking inside the house with you every room you go. So it's really extending the production from edge all the way to runtime as well. Very good.

You know, one, one of the challenges always in security in a sock for example, is just dealing with the amount of alerts and information that you're gathering. And of course there's tons of information you have access to right. In in what you do at Threat X.

How do you help manage that to make it so that the folks, the engineers, the SOC engineers, where it might be sort of work on the things that are really important and relevant, um, as opposed to, you know, chasing things down that may not turn out to be an issue they should have spent their time on? Yeah, So really it comes down to two big, um, kind of unique differentiators. The first one I mentioned a little bit earlier, but it's really about that data correlation.

Um, as you know, there's so, especially if you're a Fortune 100 company and you've got a huge online presence, which most of them do, imagine the amount of volume of alerts that are coming in. You need to be able to kind of comb through that and find the needle in the haystack. What, what do I need to focus on as a SOC engineer and analyst or incident response team First, what is most vital or important based upon my business and my applications and what that means for me?

And so really the, the concept there is we do everything, um, based upon a risk score. So that risk score can change depending on your application, depending on your organization, depending on, again, the business use case and the need of what you're actually protecting. So let's say a risk score, um, is set to a threshold of 70, and we see different attributions or characteristics that are coming in that sets that rule, it sets that threshold to a 75 organizations could then say, I want to automatically block that request.

I want to automatically, um, do something, maybe block list it, whitelist it, blacklist it, for example. And so with that concept being said, it really helps organizations kind of fine tune what to prioritize and what to focus on first. That's from a technology standpoint.

The second part is, uh, you kind of mentioned it right there, but a lot of organizations, especially in API application security, they don't have the resources to look at all the different alerts and the logging and even set up the, the tool or platform. So Threat ThreadX actually provides a, what we call a protection as a service, which is a 24 7, 365 managed service managed soc, um, that you can leverage any way you want. We've seen organizations leverage us doing tier one, tier two, tier three, complete instrument response, have full capabilities to block.

We've also seen some organizations say we have a 300 person, so team, we would just love you guys to do, uh, maybe some rule configuration or some QA when we wanna, uh, implement some type of new functionality within the platform. So it really helps kind of get the, uh, the tailored approach, but the comprehensive, the comprehensiveness of the entire suite from the technology all the way to being allowed or allowing organizations to use this from a managed security operations as well. I'm curious, do folks ever do kind of a hybrid approach?

Some of it they monitor themselves, some of it they hand off to you to handle, just I can imagine there'd be certain, certain things they want to handle themselves, but you know, they don't have to handle the universe of everything happening in their applications. Yeah, absolutely. I would say probably majority is probably 60% fall in that bucket where it's some type of hybrid approach where we might be doing tier one.

And then if we see something that is getting close to that risk threshold, again, we'll send alerts and notifications into any existing tooling or even sometimes it's still, sometimes old school, we'll call them right up and we'll say, Hey, we've seen this, um, a threat actor coming in trying to infiltrate your application. Um, we've alerted it, we've kind of put the provisions in place, um, here you go. 'cause they, they might be tier two as well.

But yeah, it definitely, it definitely, the nice thing about it is every organization can customize how they wanna leverage our services based upon their needs. Uh, I'd love to hear a little bit about, um, you know, part of, uh, the great thing about field engineers, field CTOs, field CSOs is you're working with customers all the time, so you get to experience a little bit of what they experience implementing the product, using the product or service, whatever it is. Talk a little bit about that adoption step of what it takes to start using ThreadX.

Is this a, uh, turn it on, send traffic here and you start seeing things? Or is it more involved than that? I'm being over simplistic, it's probably more involved than that, but what, what does it take to kinda get up and running and starting to see value?

Yeah, so we definitely like to call it a, the, the white glove treatment. And I think that's kind of in combination that our security operations team is the actual team that's actually helping you do the onboarding and the deployment, getting your applications online, whether you're using kind of the reverse proxy, traditional ThreadX approach or even the runtime approach. We're there step and step.

So our security, uh, operations team are experts in web application firewalls, API security runtime protection, which is super nice to have for organizations that need those types of resources. Um, but typically onboarding can last depending on the organization, depending on of, of course, how many applications APIs you have. Typically onboarding sim simply between two and three weeks.

Of course that can fluctuate and that can have a lot of different variables depending on organizations needs and uh, requirements. But, um, in general though, one of the best things we've heard from our organizations and our customers alike is, uh, this whole set it and forget IT approach where a lot of organizations can say, you know what, we, we've set it up, we've done the onboarding, deployment, things are firing, the alerts are going. And because they're leveraging our security operations, some of, some of our customers don't even log, log into our product, which is kind of also a nice kind of benefit to have, especially relying on the ThreadX security operations team expertise to handle those incidents and alerts that are coming into your organization.

So onboarding typically two to three weeks. But, um, our whole approach is that white glove treatment where you can get your nights and weekends back, and that's our kind of our, our marketing slogan that we use. But we've had a lot of customers, uh, come back and say, that's that's reality, which is, which is awesome to hear There's value right there.

Absolutely. So, so I've held off as long as they can have to ask the AI question. Um, what, what kind of questions are you getting from customers about as they're looking at or they're implementing or they're using services that all might use AI machine learning or, you know, most recently generative AI has got a lot of attention.

Kinda what do you see, how do you see that changing the approach people might take or maybe amplifying what they're already doing with threat? Yeah, absolutely. We get the question a lot.

Um, of course, of course it's hot. Um, right now in the, in the times we live in, especially to your point with generative AI and all the, all the other open source and kind of even paid for, um, solutions that are coming out to market here, um, one of the biggest questions is, is just the very basic one, how do do we look at ai? Um, a lot of my role as well, as you mentioned before, is being in the field.

That's hence the field csso point. So I get to travel worldwide. Uh, we have customers globally and it's really interesting to hear different perspectives in the UK versus the Middle East versus the United States and kind of what different, uh, regulatory bodies are doing to protect ai, to incorporate AI and solutions, and how is that gonna be developed securely.

Um, a lot of the things that we hear right now is how do we take a lot of that data and continue to kind of, again, prioritize the alerts. So really making sure that you're focused on the things that are most necessity to your organization or that includes the highest risk to your application. So how can I leverage AI to kind of automate, orchestrate a lot of that and really cut through the noise?

I think that's a lot of, a lot of it. Um, but taking my kind of AI and application and a API security hat off in general, I get asked about AI just a lot and I think for organizations where, um, I work for a lot of security vendors. I've been in this space for a while, and a lot of vendors say they use ai, oh yeah, we have ai and that, you know, we go to Black Hat RSA and every, almost every vendor right now is saying, oh yeah, we use AI no matter what.

My advice and recommendations for senior leaders and, uh, CISOs working internally, when you hear that, make sure you're really doing the stress testing on those vendors no matter what space it's in, whether it's EDR or SIM or APIs or ticketing systems, whatever it might be, really stress test. Those companies really figure out how are they actually incorporating ai, um, how are they incorporating it within their own internal processes, how they continue to develop, make sure it's secure. That's also, you know, being from a cybersecurity aspect that's super, super important, um, because, um, marketing can say they, you know, the tool and vendor uses ai, but really, really test it out and, uh, make sure it works for your organization.

Yeah, I think, uh, particularly regenerative AI being, it's, it's a relatively new topic. I mean, it's really just been a, a little over a year ago since most of us learned about it. Right.

Um, sort of the data going into those models and data protection and how do we know we're not sending things outside, or if we're training models ourself, make sure that that doesn't leak into, you know, more base models that are publicly available. Seems like, uh, uh, I dunno if it's a greenfield, but there's a lot of opportunities for companies like threat X to really help customers understand what's happening and how, how to protect when that does happen. Absolutely.

Yeah. I think in the API space in general, API and application space, there's a lot of, um, lean way, I think for organizations to incorporate AI effectively in their products, to not overdo it, but also to make sure that they're leveraging in the best responsibility. So absolutely, I think it's still, I think in cybersecurity in general, um, kind of going back to that, the marketing fo there, it's, uh, there's a lot of room for AI to accurately and effectively help organizations.

So I think we're just scratching the surface there and we got a, got a long way to go, but it's, it is definitely an exciting time. Great working folks. Find out more about ThreadX, maybe get a demo, get engaged, start, start seeing the product and the service.

Absolutely. com. Um, you can actually sign up for, uh, trials.

You can get a demo, a request form right there. Uh, in addition, a little plug, uh, I also have a podcast called Exploring Cybersecurity that can be found right on the ThreadX page under podcast, um, where we deep dive into all aspects of cybersecurity news and trends and bring on guests from all different avenues and walks of life. com, uh, where you can find all your information on, uh, demoing and all our products and services that I mentioned.

Excellent. Well, thanks Jeremy. It's been a pleasure talking with you.

Jeremy Ventura, who is, uh, filled CSO with ThreadX. We'll talk to you again soon. Thank you so much, Mitch.

Thanks for having me. You bet.