ThreatX by A10 Networks delivers real-time, behavior-based protection that secures your APIs and applications with automated, risk-based blocking—eliminating threats without manual intervention. Its unified platform replaces alert-heavy, fragmented security tools with easy-to-manage, 24/7 monitored defense, giving you clear visibility and peace of mind against evolving cyber attacks. Watch a full demo of ThreatX brought to you by SourceForge.
Request your personalized ThreatX demo here
In this SourceForge Product Demo Showcase, we speak with Carlo Alpuerto, sales engineering manager at ThreatX. We discuss the recent acquisition of ThreatX by A10 Networks and its impact on web application and API security. The conversation covers the importance of APIs as high-value targets, ThreatX’s use of behavioral analytics, and the benefits of a unified platform with a 24/7 managed Security Operations Center (SOC). Carlo provides insights into the challenges of API security, the unification of data, and the simplification of security processes. The episode also includes a live demo of ThreatX’s capabilities in protecting against various threats like DDoS, bots, and more. The discussion highlights the importance of a comprehensive and user-friendly security solution for overworked security teams.
Watch the product demo here:
Learn more about ThreatX.
Interested in doing a Product Demo Showcase? Contact us here.
Show Notes
Takeaways
- APIs are increasingly targeted by attackers due to their value.
- ThreatX offers a unified security solution that simplifies management.
- Behavioral analytics play a crucial role in threat detection.
- Risk scoring helps prioritize security responses.
- Layer 7 DDoS attacks require specialized protection strategies.
- User experience is a key focus in security solutions.
- Integration with existing security stacks enhances effectiveness.
- Customer feedback is vital for product evolution.
- The future of security will heavily involve AI technologies.
- Simplification of security processes is essential for overworked teams.
Chapters
00:00 – Introduction to ThreatX and A10 Networks
02:56 – Challenges in Cybersecurity and API Security
05:48 – Unified Security Solutions and ThreatX’s Unique Approach
08:47 – Live Demo of ThreatX Platform
12:02 – Behavioral Tracking and Risk Scoring
14:44 – Integration with Security Stacks and Third-Party Solutions
17:25 – User Experience and Simplification in Security Management
20:35 – Future of Web Application and API Protection
23:29 – Real-World Testimonials and Customer Feedback
26:21 – Upcoming Features and Enhancements
29:26 – Conclusion and Key Takeaways
Transcript
Beau Hamilton (00:00.76)
Hello everyone. My name is Beau Hamilton, Senior Editor and Multimedia Producer here at SourceForge, the world’s most visited software comparison site where B2B software buyers compare and find business software solutions. In today’s episode of the SourceForge Product Demo Showcase, I’m joined by Carlo Alpuerto, sales engineering manager at ThreatX, which was recently acquired by the A10 Networks family earlier this year to bolster web application and API security.
In this episode, we’re going to dig into why APIs are such high value targets, how ThreatX uses behavioral analytics to stay ahead of attackers, and why a unified platform with a 24-7 managed SOC, that’s Security Operations Center, just makes sense, and why that can be a real game changer for all the overworked security teams out there. Plus, we’re going to go through an actual live demo showing how ThreatX correlates threats across DDoS, APIs, bots, and much more, so you can see what modern intelligent protection really looks like.
With that said, let me introduce Carlo Alpuerto. Carlo, welcome to the show. Glad you can join us.
Carlo Alpuerto (01:01.526)
Good morning both. Thank you for having me.
Beau Hamilton (01:03.618)
Now, can you give us an overview of A10 Networks and just what they’re doing within the cybersecurity landscape?
Carlo Alpuerto (01:09.206)
Sure, when we look at A10 Networks and where it was rooted, it’s about application delivery, making sure that we have the proper load balancers in place and effectively ultra low latency, right? Oftentimes focused at service providers that might need that super fast speed, but now also in the enterprise and commercial space because many companies are hosting their own applications for retail purposes and other business there.
But when we think of low latency and application delivery, we also have to consider whether or not the application has uptime at all. So this is where ThreatX has come into play.
Beau Hamilton (01:51.374)
Yeah. And I imagine we’re going to hear a lot about, kind of the unified approach of security with this recent acquisition, which is almost breaking news. I know it feels like it almost feels like yesterday with how fast this has flown by, but it was acquired and kind of merged into this, uh, ATEN’s networks, ATEN networks family in February of this year. Is that right? Now, um, can you talk about just why ATEN wanted to acquire Threatnex in the first place and just again, like how it fits well with ATEN’s other suite of products?
Carlo Alpuerto (02:10.87)
That is correct. Yes.
Carlo Alpuerto (02:21.942)
Sure, and this is something that we’ll be talking at at one of the greater conferences this summer. But really we’re here to make a fuss, as we’ll call it, right? Futurize security and that application delivery for A10, but also unification of data and information. And we’ll talk to why that unification comes into play, but also simplification, right? Our goal is to empower our users, make things as easy as possible for them.
Because as you had mentioned in the introduction, those SOC teams are overworked.
Beau Hamilton (02:56.654)
Right, simplification, unification, all those iffications are important. I know the security and privacy threats are just, they’re only increasing, right? Especially as we continue to transition systems online and also get more connected with these AI tools and software that’s just becoming more commonplace. What’s a challenge that, in security in general, I know this is a pretty broad question, but what’s a challenge that people should really be aware of in the cybersecurity context.
Carlo Alpuerto (03:30.582)
There’s so many challenges and so many approaches. Yeah, exactly. I mean, my own history, I come from least privilege management, which is now zero trust. also worked in the sim and source space, right? The automation of things, but let’s, you know, let’s go back to that statement of fuss, right? Futurization and evolution of products is one thing, but the unification of data and the usability of it is another, right? Each system should feed
Beau Hamilton (03:31.924)
I know. Is there one that comes to mind?
Carlo Alpuerto (03:59.482)
one another and because a lot of solutions are Frankensteins together, the ability to do so is not as easy as the dream that drives it, right? Yes, very large, large corporations that have the teams available can do so, but you know, that unification of data is not so simple. The simplification of it is what, you know, really comes into play, whether the solution itself is easy to use, but also whether or not it’s assisted, right? So these are things that our stock team can help with as an augmentation to existing teams that are out there.
Beau Hamilton (04:44.546)
Now, what about in the API space? Are there any particular challenges developers and security professionals have to navigate here?
Carlo Alpuerto (04:52.406)
Well, that’s just it. You mentioned two different teams there. Developers on the shift left, the security teams and sec ops teams, somewhere in the middle and to the right hand side. With regards to API security, that’s a very broad term. There’s API security from the vulnerability aspect. So we are at the shift left and mediating and mitigating those vulnerabilities. It takes time. Those are things that have the development cycles, but now you have QA, staging, UAT, right? All these things and change management that need to come into play. So resolution of that takes time all the while that vulnerability exists. There’s API mapping and attack surface management, right? What APIs do I have? The shadow APIs and the concerns around those. There’s the authentication and authorization, things that an API gateway can play with.
All of these are complementary solutions to what we can provide, API protection. In our realm, we look at it from the outside in to protect against the attacks using information pulled from the other various sources as necessary, but more focused on whether or not an API is vulnerable, whether or not an API is known. We are looking at the attacks as they are coming in on the inbound.
Beau Hamilton (06:18.478)
Yeah, there’s so many factors. mean, the long list, you mentioned a bunch like the scalability issues. Another thing you hear a lot about is just the various governance issues and kind of standardization requirements and whatnot, which depending on, it kind of gets rolled back and moved forward depending on different kind of macro conditions, political policies and whatnot. yeah, just makes sense for why a unified system would really be particularly helpful to discover all these threats and get a handle on them before they become a problem. Now, before we jump into the hands-on demo, which I’m really excited for, by the way, can you summarize some of the just top use cases of ThreatX and, again, just maybe talk about why it stands out from some of the other solutions in this space?
Carlo Alpuerto (07:07.968)
Yeah, great call out. When we look at that unification that we talked about right ThreatX is itself rooted in next gen WAF, but it is a unified solution all built within one platform. For the purposes of not only that web application protection of firewalling capabilities, but applicability to APIs as they exist from Layer 7 DDoS and the various types of attacks there, as well as attacks from bots and other unknown entities.
When we think of that unification from that perspective, it gives us a comprehensive solution that is feeding off of itself as opposed to having to rely on those Frankenstein connections. The simplification aspect. You’ll read reviews online and you can speak to some of our customers where it’s about that stock team, right? I have all of this balance within here, but yet I need time dedicated to learn a solution, to use the solution to its fullest. By having our augmentation on product and capability specialists, we can make that so much faster for lot of our customers, and we do.
Beau Hamilton (08:23.714)
Awesome. Yeah, I’m going to have a question for you later about kind of some real world testimonials from, from companies that have used this product. So I’m excited to hear about that. But before we, we get into that side of things, thanks for laying the foundation for us. And I think that’s a perfect setup for what we’re about to see. So let’s, let’s have you share your screen and maybe you can give us a walkthrough of how ThreatX works in practice.
Carlo Alpuerto (08:55.988)
All right, good news is I’m not a slides guy, so we’ll do this part really quickly, but really just to recap on the items that we spoke to, right? It’s about protection from the outside in, so having that shield as it is displayed on here, regardless of what is behind that shield, right? Oftentimes I equate it to a castle wall, right? A castle wall doesn’t necessarily care who’s behind it, but more on who’s attacking it and what types of attacks they are using. We do this by deploying to various hybrid scenarios. So we are a SaaS-first business, but we can deploy to on-premises, whether it is on-prem from the perspective of a physical DC and the virtualized environments within there, or even to various cloud environments, whether it’s AWS, Azure, GCP, things of that nature.
Protection is applied in line to the traffic and live time, right? Without being in line to it, you’re only looking at mirrors. Your effort in that scenario is alerting, and we already are aware of alert fatigue. So our goal is to provide that protection upfront. And we do so a number of different ways. When we consider how your common WAAP solution works, or WAAP, right, as Gartner coined it, WAAP, Web Application API Protection, right? It really should feed off each other. So I’m going change that WAAP, right? As I’ve been starting to hear recently to Web Application Protection Platform, right? Where everything is an all in one. And the benefit to this is we can use that information to observe the behavior of the various entities, just as UBA is now UEBA.
We want to keep track of what these entities are doing such that we can apply protection not only against the individual attacks, we’ll get into this more as we get into this, but from the entities performing these attacks themselves. And then couple this with our SOC team inclusion for anybody that might need rules updates, a hand holding because they are a one man or two man shop and women, two entity shop if we will.
We can help those teams out as necessary, or we can even augment the larger teams that are out there. Just to talk really.
Beau Hamilton (11:27.918)
Very cool. Yeah, I like the, I just want to say I like the Castle wall analogy and appreciate the kind of breakdown of some of the acronyms because that can always be a little bit kind of confusing at first. So appreciate that.
Carlo Alpuerto (11:42.386)
Absolutely. Looking really quickly, I’ll just blow this out. As traffic exists, when we deploy in SAS, our stock team will do this on behalf of the customers. So again, taking load off of their plate. Well, all we request is that we get whitelisted against your firewall so that our ingress does not get blocked there. But in the end, it’s really just DNS mapping.
This is of course greenfield. This does not include CDN or any other downstream solutions nor any upstream solutions like an API gateway that can further augment and, you know, compliment our solution. You know, we’re just looking at a greenfield here, but really it’s an inline flow to traffic. This again, as mentioned, can be used in conjunction with a self-hosted solution wherein
We might provide our ADCs for the purposes of load balancing and then upstream from that or behind that would be our sensors. Now I use sensors here for the purposes of simple understanding. It’s really a scalar farm or a sensor farm that is being deployed. And we’ll talk to the dynamic aspects of that sensor farm as we get further into the prezone. But it’ll play into the DDoS aspects or DOS aspects because layer 7 doesn’t necessarily require a volumetric attack in that space. So all things that should be considered there.
Carlo Alpuerto (13:20.118)
That flow of traffic really should just follow this purple arrow, right? Ultra low latency, process as fast as possible, make sure that everything happens within the scope of the traffic that is there. However, there are always questionable items, things that don’t necessarily have an attack signature, but yet you want to give added scrutiny too.
When we experience those, we do send it out to our cloud gateways where we host the data and this Hacker Mind, which we’ll be discussing more in that event coming up in August. I’m sure a lot of you know it. But when we discuss this Hacker Mind, it is a a threat processing engine. And with that, it will look at the cumulative activity of previous events as conducted by select entities and then send that information back to those scalar farms so that all the rules are updated locally, they are all processed locally and as fast as possible.
It is this very same UI and cloud environments that our SOC team can access as well as usage of APIs. So I talked to SIM and SOAR integration. Yes, we can send our information there. And if you have a configured SOAR, the correlations that you can make on SIM might extend beyond rules and alerts that we provide so that now you can use your own threat hunting methodologies and apply those to a SOAR, which in turn can update rules on our side by way of the APIs. Again, comprehensive solutions, each working with each other.
Beau Hamilton (15:15.544)
Yeah, well, was going to say, yeah, thanks for kind of explaining and showing us this sort of conceptual view of the back end architecture. Cause I think this is again, to kind of lays the foundation and a lot of people kind of gloss over or kind of they don’t necessarily appreciate or understand fully what’s going on behind the scenes. When you look at some of these UI and software interfaces, right? So seeing this kind of how it all works is really beneficial here. So I appreciate it.
Carlo Alpuerto (15:45.6)
So let’s get into my UI and like any good UI I’ve timed out. But as it pertains to security, there are a number of different ways in which it applied, different ways in which we need to use that. And the first thing we offer is a tenant that is separately created for our customers. So all of that data is processed separately from everyone else. But even within there, some of our
MSSP, some of our service providers, some of our hosting customers, they in turn might need multi-tenancy and as such they would have their own particular tenants within there. I’m just going to transfer over to this one.
One thing I want you to catch on this, and this harkens back to that note of simplicity, is what some might perceive as a lack of information on screen. I had one customer, prospect at the time, now customer, ask, how come I am not seeing alerts on all of these blocks that happened? Why would you want to? They blocked, they happened. Yes, we have a blocked request screen and dashboard, but the goal here is to apply focus where it’s necessary. I’ll just extend out my time.
But when we look at the items here, we want to know general traffic. What is the general usage of my environment? How much protection should I be considering within here? And this gray graph gives us an understanding of the total traffic, while the blue is representative of the blocked traffic. I do want to point out, since a listener is bound to ask, well, how are you blocking more than you’re receiving,
Carlo Alpuerto (17:32.054)
We’re not there are two different y-axis ease the total traffic on left up to 25 K in this example or this time range and then the block traffic on right to 5,000 right, but the bit to catch with this is the threat entities themselves, right? We’re all familiar with threat maps. Top targets will just be an understanding of who’s getting hit the most. And we can see that with the separation of sites. But I wanna focus on the threat entities. I did talk about using information against entities.
Now, why is ThreatX different in this case? Your classic WAF, even the NG WAFs, commonly look at the individual attacks as they get in. We’ve always heard the adage of security has to get it right, you know, 100 % of the time or as often as possible. But because it doesn’t, right, that’s why we have monitoring like SIM and responses like SOAR. But rather than have to get every request right, we also want to address the entities so that we can observe what might be a prelude to a future attack, right? Going back to the difficulty of API attacks, they’re not always as nuanced as some of the common WAF attacks, right? And as such, the signatures there aren’t always so evident and so obvious.
So creating rules is difficult. What we want to look at is a cumulative effect of activity, right? Is an entity doing credential stuffing? Are they throwing various usernames, are they password spraying, are they doing things of that nature, are they scanning and doing reconnaissance against my environment by way of enumeration, are they testing timeout periods, things of that nature. So taking all of this together, we would provide a risk score that applies to all activity cumulative to that entity itself.
Beau Hamilton (19:43.438)
I like the score in the, I mean, it’s the kind of red disclaimer, these are the red color, 100, I mean, it definitely draws your eye, right? It makes you realize the importance of this threat. Now, is this a part of the progressive blocking feature?
Carlo Alpuerto (20:04.872)
It is so you know we’ll get to that in a second. Actually, while we’re there and since you mentioned it, you know, let’s talk to the options for blocking types right as we configure customer sites within and these are just my own honey pots and demo sites as we consider those adding in. We gather information. We work with the customers cooperatively to gather it, but there are two items that are oftentimes day one activity manual blocking.
Request blocking. Right, these are things that some customers who come to come to us by way of I hey, you know I am actively under attack. I need help right away, right? We are not, you know, a the Mandiance of the world. We are not flying in on the parachutes and resolving these items. However, we can from this perspective. Because with manual blocking, this is where your legacy WAF started off. These are things that we put down on a list and we say, don’t want activity from XYZ entity. Very easy to do, very difficult to maintain. The scalability and the number of share attackers make this, I don’t want to say an unusable option, but a very difficult option to maintain. So a lot of NG WAF, the Next Generation WAF Solutions.
We created rules, right? And again, that’s where ThreatX started off, wherein you can use regular expressions, tokenization of information, right? There’s a lot of patterns that are tied to this. And we can create things and our customers can create things that are as broad as a geo fence. Maybe I don’t do business outside of my geo region, or I don’t do business with a particular geo region or regions. And that’s very broad in its scope but that could lead to false positive. So we also allow the nuance to say, I don’t allow any activity going to this URL and this URI unless it comes from entities matching this information or having these headers within the HTTP, right? Very nuanced and precise capabilities, but because of that, prone to missing, right?
So this balance in rules is the difficulty that a lot of and firewall users are challenged by. Constant updating, the behavioral tracking, the ability to use intensity, frequency, no, by frequency I mean how often, information like attack classifications to a small degree where those attacks are coming from. There’s various criteria that are applied to the risk score such that when risk-based blocking is enabled, it is at that point they cross a threshold and from there they might end up being banned outright. We’ll see that in entity discussion. But this is not a day one activity. This is something that for my customers, I recommend a month to activity at least a week three or as much time as possible before enablement. We and our SOC team want to work with you, the customer, to say, OK, based on these baselines, based on these observations, we think these could have been false positive. But rather than block it because it’s disabled, we’ve observed. We’ve made exceptions. At that point, you can decide, do we continue observing? Or do we go ahead and enable?
Beau Hamilton (23:51.15)
Yeah, so you need that track record before you kind of proceed with the next step.
Carlo Alpuerto (23:55.048)
Exactly right. probably noticing within here SSL. Just note that that’s another service that our stock team does for the purposes of clients to censor negotiation. We can manage those certificates on your behalf and further minimize the amount of administrative overhead that is on your particular plate. With that said, let’s poke at the threat entities. I am going to grab a couple here only because it’s somewhat live, I do have, boring, good, boring, boring. Okay, benefit of live, right? When we look at the attack patterns here, usually, in your classic WAAP solutions, you would see the individual lines. You would see an item that was blocked, just as this was.
And in this case, due to effects of information disclosure, attempted access to backups with sensitive files, right? Things of that effect. And there’s intelligence within here where available that can be sent off to those Sims for the threat hunting purposes, but note that this was blocked, right? Again, we didn’t see this individually on the dashboard because of that need for simplification. The next request also subsequently blocked, but look at the continuation. When we see the next activities they were allowed through.
But because at the time these scores comprehensively passed a threshold, which can be changed, the entities ended up blocked. Right? Regardless of good or bad requests, no further traffic would be allowed through.
But then we issue a watch. Why would we? Behavioral tracking, call it what you will, ML, AI, none of those solutions know every business. And as such, we don’t know necessarily whether or not this could be false positive. And we don’t want to be the cause for that false positive. So we allow for reset and we allow the entities to try again. Wherein they might get blocked.
We might allow them to be through, right? It could get blocked again. This one likely blocked by a rule that had a block statement, and we’ll talk to that in a second, but gave it a low risk score, but cumulative activity enough such that it ended up blocked again, right?
We will continue this cycle. This is the automation that allows for simplification of usage because now I don’t have to keep up with the rules. The system is watching this activity for me and making up those rules as we go in the end on a, you know, a future strike. It will get banned outright. Yeah, we’ve given it enough chance. Don’t bother anymore with wasting compute power.
Beau Hamilton (27:01.326)
And you can fine tune all the restrictions and thresholds required to tighten up this behavioral tracking pattern.
Carlo Alpuerto (27:16.702)
Yeah, absolutely. Let me drop that down just to make sure I capture that for the conversation, right? Normally rules discussions I don’t get into, but that’s a good point. We’ll talk to some of the nuance there to that because it will be applicable to how protections are put in place. But you don’t have to even wait for that, right? You’re talking about fine tuning as we go. If you happen to be on the dashboard and you want to ban it right now.
You absolutely could, right? The good news is with exceptions that are made, whitelisting per name in here as it applies, you can do so on a temporary basis. So think of any of the customers that are going through pen testing, right? Pen testing contract for, let’s say a week. The first day is administrative work. The next day is about testing the security solutions. Oftentimes we will see these attacks light up the board and they’re blocked.
But now those same pen testers need to test the solution itself. So you can allow for an exception and even set it on a temporary basis. So do this for three days, right? If they want more access, well, they have to ask for it as opposed to me having to go to my ITSM and unsetting these, you know, what could be an exposure or a backdoor if left unchecked.
Beau Hamilton (28:43.746)
Right. Now, can you talk about maybe some of the integrations that are currently existing in various security stacks, say SIEMs or third-party WAFs? How does ThreatX handle these integrations? And perhaps, I don’t want to jump ahead if you have some other tidbits you want to share too.
Carlo Alpuerto (29:06.485)
Yeah. A little bit of a jump, but not a problem at all, With regards to integrations, number of options available to us, right? Notifications, as we’re seeing on the left-hand side here, as well as this log emitter. Notifications are exactly that, right? Commonly emails, but we also allow for web hooks. So if you have, you know, probably the world’s most famous ITSM out there allows for web hooks, you can create tickets out of each one of these, but again, do you really need to for blocked events or, you know, questionable, i.e. match events, right? Those would be better off sending to a log aggregation solution like Data Lake or a Splunk type solution, or even to a SIM like a logarithm, a QRadar, Sumo logic, what have you, right? So that log emitter is actually an open capability.
It’s not a built integration per se, such that each time one of those third party vendors updates their technology, we have to go through the process of making sure that, you know, we are still capable of interacting with. It uses a, an encrypted TCP connection to send JSON log files that way. And most any solution, I haven’t seen one yet that cannot absorb the information allows it to come in such that if it’s a Qradar AQL query that is then generated to create an alert, use the information within those logs such that it can feed those additional logs.
Great tie in, but let’s talk to further protections, right? And that unification that was mentioned. ThreatX provides the protection for WAF API DDoS bot. All of that information within that database that you had mentioned, all of that information processed by that hacker mind as we have within there.
How do we apply these protections? How do we apply action ability? How do we address the rule matching that I had written down, right? When we look at this.
Carlo Alpuerto (31:26.408)
Our ability to create rules, rules that I have on this screen, and you can push pause and look at these as necessary. These are only the rules that are applicable to the individual customer. That very same SOC team curates rules on a daily basis. So our usage of threat intelligence, our usage of CVE notifications, our usage of zero day news, right? That team updates rules on a regular basis that we do not expose. Do not want them out on the dark web. Do not want people reverse engineering to try to find ways in. So we just simply don’t expose them. That’s the benefit of having that SOC team. We can help troubleshoot. If, however, and when a customer wants to create their own rules, blocking is part and parcel to any protective solution. However, we can track, meaning we can keep watch, while at the same time affecting that risk score.
Just as for production environments or any environments with PII, PCI, PHI type information, you would want to be more aware of or assign higher risk. You can allow track, but then you can give it that higher risk score such that if there is no delay, if there is no cool down period, if you will, between transactions, we allow for the first, but then if these grow and accumulate, you cross that threshold, you end up blocked.
Beau Hamilton (32:58.766)
OK, so there’s some leniency there.
Carlo Alpuerto (33:01.556)
Yes, absolutely. We can interrogate. Meaning. We throw a challenge and we find headless systems right if select you know criteria that we add, you know, URL, you or I, whatever it might be. Presents itself as a headless system. Well, then at that point we would block it. But then the one that we haven’t addressed yet and you know the continuation of a tens low latency and making sure that applications have uptime is that layer seven DDoS, right? We’re all familiar with layer three and four, the volumetric attacks, and we protect against IPs and the entities behind them. But what about the layer seven? Why is that different? Why is that harder? Layer seven can be volumetric to a degree when you see HTTP floods.
And in those scenarios, we would tarp it. Rather than run the cycle in the gamut of request response, request response, right? We know how that is and attackers will do that thousands, millions of times over. We can tarp it. And the benefit to the tarp it is rather than respond right away, we slow it down. Yes, that keeps open sessions on our sensors, but it keeps it off of your origin hosts, but it also keeps the open session on the attacker.
Our scalars, you know, just, whoops, a little too far. Yeah, I’ll use this one. That scalar farm that I had mentioned, the dynamic capability of it is such that our sensors are hosted within. And the benefit to the dynamic aspects of it is if in the event of volumetric attack, this will grow up and this will include in deploy more sensors internally to it. The same goes for your holiday shoppers or any busy seasons, quote unquote, that customers might have. But think of that dynamic aspects and think of layer seven attacks. Layer seven doesn’t have to be volumetric. It could be a slow rate attack. Slow posts also being slow rate. By name, slow lowers is probably the most popular.
But those types of attacks trickle an HTTP request, meaning it will start a request which opens a session, but rather than send a full request, it will trickle in the remainder of the HTTP. What in the end could be a clean request, albeit delivered very slowly. The problem with that is there are no real rules yet to process because it hasn’t been fully received, right? And as such rules, management of those types of attack is very difficult. By being a reverse proxy, by buffering those requests such that they have to be complete before we send it on, yes, our sensor can be rendered unresponsive, but the dynamic capability of that scalar farm, it will tear down that sensor, it’ll spin up a new one.
Beau Hamilton (36:18.734)
Okay, thanks for breaking that down.
Carlo Alpuerto (36:22.004)
Excellent. So let’s come back. Do these themselves right when we do this, you know, and we have customers that. You know, like many on this call, you know, like many on my team. Do the Jason right? Get into the code, get into the nitty gritty for those that don’t have the time to get into all of that. Use a visual editor where you can add multiple criteria to this and then to those that don’t even have that time leverage our stock team.
We are here not only to stand that up for the purposes of your usage, but for the purposes of ongoing management. I need a rule created. I need troubleshooting assistance. I like to create my own rules, but I need a sanity check. Can you help me make sure that this is done right? And then even to a small degree, though not an MSSP ourselves, we do have some alerting on our end such that we can also proactively reach out to customers. So our customers do run the gamut of one to two person shops to full large teams that have multiple things to manage, but yet will make life easy for them.
Last bit I want to talk to you is something that we spoke on early with regards to API. Security right, we talked about vulnerability. We talked about authentication authorization, but discovery right there are a lot of great solutions out there that deploy crawlers that find all the APIs and endpoints associated with them. But because they’re top heavy, they run once in awhile. Right, they’re not done all the time because.
Now they potentially introduce slowdown to the systems. We are looking at the requests as they come in. We see target domains. As well as the paths, i.e. the endpoints that they are going after. As we have this observation, whether it’s a 200 response because it’s a good request, it’s a, you know, 403, you didn’t get access, but yet confirmed it was there, right? Because it wasn’t a 404. Well, now we start putting these items down within an API catalog.
The API catalog, I’ll just talk to it in brief. The API catalog is meant to keep a running tab of APIs and endpoints as they are observed. By using the information observed in real time,
We are protecting first and foremost, and then we are cataloging the APIs as they come into play. So by doing so, think of shadow APIs. Our ability to identify APIs that don’t appear in the API schema, because maybe the API schema wasn’t updated, maybe because the APIs were brought onto play because I’m using a third party developer or there’s an open source technology that I haven’t fully documented yet or even possibly even more dangerous, the zombie API. Those APIs that were supposed to be decommissioned because they did find a vulnerability, but now we see activity against them. They’re still there. Those are very dangerous and could pose a real threat to a lot of companies looking to protect.
So that said, there’s a lot more that I can get into with regards to locations and rules and setups and configs. But these are all things that I would invite customers and attendees to this podcast to go ahead and request a demo. And we’d be happy to run this against some test websites as necessary.
Beau Hamilton (40:44.558)
That’s great. Well, I just got to say I’m definitely a sucker for a good user-friendly UI and one that doesn’t overload my already overstimulated millennial brain. And this one seems pretty intuitive to navigate. So it’s pretty welcoming in that sense. And then just with all the finer details of the rules and some of the block requests, which again, I think makes sense why you wouldn’t necessarily want to include it, complicate the picture on the main dashboard. I think that’s a good design choice there.
But yeah, thanks again for all the insights here. think we’re going to have a link down in the description as well as in the SourceForge article about where you can go to schedule a demo if you’re interested in kind of getting a hands-on kind of feel for this platform yourself.
Can you mention the link while we’re on the topic? I believe it’s a10networks.com/demo, is that right?
Carlo Alpuerto (41:47.168)
That is correct. Yes, a10networks.com/demo. Absolutely.
Beau Hamilton (41:49.72)
Awesome. Well, thanks again for walking us through the ThreatX platform and just giving us a demo of the product. Obviously, there’s a lot to cover and only so much time, but hopefully viewers get a much better understanding of just how this product works in action. And now that we have seen it in action, I do want to ask some kind of more conceptual closing remark type of questions. I’m curious, what are some of the main takeaways you hope viewers will, I guess, remember?
And maybe you could summarize some of the top few features that this platform offers.
Carlo Alpuerto (42:29.59)
Sure, and that’s easy to remember using that fuss, right? Using that featurization capabilities, right? Constantly evolving solution, right? One of the things that I am most happy for having come over with the acquisition is the amount of resources that A10 offers to our own developmental efforts and testing efforts, right? The featurization of this, when we look at A10’s focus on hybridization, one.
Again, we can install to SaaS and or self posted the focus on security enter ThreatX, but also their focus on AI, right? As we futureize this, as we get more capabilities to that hacker mind, this is going to be a great thing and I’m looking forward to it strongly. But with that said, you know, to the customers looking at it as it is the unification of that data. It’s not a Frankenstein solution.
We have the WAAF, the API, the DDoS, the bot protection within here. We can use that information cumulatively to give those entities a risk score and protect from attacks possibly before they even happen, right, as that reconnaissance and probing is happening. And then the simplicity of it, whether it is the simplicity of the UI, API, unification where SOAR might be applicable or even leveraging our stock team.
Our goal is to make it as easy as possible because we’re already over.
Beau Hamilton (44:00.974)
Yeah, just anything you can do to prevent that future headache is huge. yeah, I think just the unified approach and simplicity this platform offers, I think is huge. And I think this leads to my next sort of answer for my next question. But that’s my, you I’m curious, like for the the CISOs watching the security professionals with influence at their company, you know, determining what kind of platforms to adopt for their company, why would you say ThreatX matters or maybe should be considered for adoption?
Carlo Alpuerto (44:36.16)
Well, I’ve been in security for a little while and it’s always been a tenuous balance of what is productive and what is secure, right? If we’re thinking about the CISO level, it’s business first. And if you’re getting in the way of productivity, well, you’re less likely to be involved in their security program. But our goal is to make sure that those websites are always up. anybody in that retail or delivery space or anything with a business or mission critical website. You know, we want to make sure that they stay alive, that their data within them is not breached. by breached, I don’t mean only egress and a stealing of information, but a changing, right? Breach is not limited to loss of data, but change of it, or even unavailability of it. Right? I’d hate to be that person going in for surgery and well, the doctor doesn’t have my information available, right? I know that’s a broad example, but things of that nature that we should be considering. And then the time that your teams get back, because it’s simple, because they’re augmented by our own team. You can innovate because we’re going to mitigate all these items for you.
Beau Hamilton (45:54.934)
Now, I know it’s one thing to obviously talk about how great a product is, but it’s another to hear about the product from a community and kind of get some real world testimonials or reviews. I’m curious, what kind of feedback have you received from early adopters or maybe beta users who are using the platform currently and have worked with you guys?
Carlo Alpuerto (46:17.226)
Yeah, speeds delivery is one right. I mentioned prospects at the time customers now that have come to us under attack active attack and because the SOC team can spin up these sensors and get the configurations in place. You know, in short time I’ve seen customers run in protected mode within two hours, right? I know I know we live in the world where we don’t normally give numbers. That’s just an experience that I’ve had.
Right? Oftentimes I would say a couple hours otherwise, but that’s a reality. The addability, you know, early feedback, always that SOC, right? Whether that behavioral tracking needs to be changed or affected because we want to affect differently for production sites versus others, having that SOC team there is a mainstay. And as such, you know, that adoption rate makes it that much easier.
Now I’m not going to come in here and say that we’re flawless, right? But early feedback is also about having that feedback capability, being involved in the development and being able to provide your own voice and give feedback to different ideas on solution. That featurization, that evolution that I spoke of, it only comes by way of involvement and our customers have an involvement there.
Beau Hamilton (47:42.466)
Yeah, and products, they are not perfect overnight, right? You’ve got to keep refining them, introducing new features, seeing what works, what doesn’t, gathering feedback from these early adopters and beta users. These guys are probably very excited about what’s coming down the pipeline, what’s currently in the works over at ThreatX. Can you talk about some of the upcoming features or enhancements planned that maybe are right around the corner?
Carlo Alpuerto (48:11.51)
Right now we’re going through a migration so that we can tighten up more of the security and the speed with which the UI itself is even presented, because we know the speed of the processing at the sensor level, but there’s a lot of unification efforts that are going on with A10 itself, whether it is implementation and incorporation of AI that A10 in general is working with the unification under A10 control, which is their single pane of glass, as much as I hate to use that term, but it’s a term that everyone understands, putting all of that capability into one. But now, again, as I had mentioned, what excited me about having more resources through A10, a lot of those feature requests that have been made are just coming up to speed. So the rapidity of which we can deliver those has been made that much better.
Beau Hamilton (49:08.312)
Yeah, and I think you see a lot of companies in the software space just releasing features that aren’t necessarily requested or particularly sought after. And they’re kind of forgetting about some of the finer kind of mechanisms, the backend that is really equally, it’s more important, you know, as long as like the main functionality is consistent and continues to be built out and robust. So I think there’s something to be said about placing some importance on just making sure that system is good to go.
I’m able to kind of weather this sort of AI wave that we’re headed into, right? I want to kind of leave with one final sort of big wide reaching question for you. And I’m just curious, what, how does, how do you and your company, A10 Networks envision just the evolution of web application and API protection in the coming years, you know, especially in the context of these emerging technologies like AI.
What’s like, what is something that you know you’re concerned about, you’re looking forward to, you know, just keep it a, keep it aware of.
Carlo Alpuerto (50:15.19)
Well, I guess this also goes back to roadmap capabilities, not necessarily roadmap within ThreatX, though applicable there as well, but roadmap to A10. It’s announced on the website and AI firewall, right? But when we think of how AI itself feeds and delivers, oftentimes that’s by way of API, right? Use those APIs to gather information from the various sources for the learning mechanisms. But now when delivering the information back out, oftentimes by way of API, the question just happens to leverage or the AI happens to leverage an LLM, but once that is a large language model, but once that is sent off for the data request, right, it’s the API that gathers it as opposed to, you know, the good old days of SDKs and direct programmatic interfaces.
Beau Hamilton (51:12.758)
Right, right. So you gotta, yeah, I think, yeah, that’s interesting to keep in mind. my mind goes to the API marketplace for, you know, something like chat GPT and sort of this handing off of data is interesting to think about. And it’s good to hear that you’re aware of it and trying to bolster the security there. For viewers, for listeners who are interested in exploring ThreatX further, or just maybe interested in requesting a demo for themselves, where should they go?
Carlo Alpuerto (51:42.454)
On our website, you can go to a10networks.com slash demo. From there, you can request the demo and we can do so very much similar to what we have here except applicable to your own particular usage and or from there set up a POC and we can get you set up again in quick time.
Beau Hamilton (52:01.92)
Awesome. All right, that’s atennetworks.com slash demo if you’re interested in scheduling a free demo. And yeah, again, we’ll link that in the accompanying SourceForge article as well as down below in the description to help you guys find it. But Carlo, it’s been a pleasure. Thank you for all the insights. You are a wealth of information. And I think listeners have learned a lot from this conversation, so I appreciate it.
Carlo Alpuerto (52:25.448)
Awesome, Beau, thank you for having me.
Beau Hamilton (52:27.714)
Thank you everyone for watching. I’m your host, Beau Hamilton. Make sure to subscribe to stay up to date with all of our upcoming B2B software related podcasts and product demos. I will talk to you in the next one.