Unspoken Security Ep 44: They’re Hacking the People!

the fundamental thing like roads never changed, right? And in other words, when you're driving your car, right, there is not that many enemies who want to kill you, right? In cyber world, it's completely opposite. No matter which car you're driving, if you don't really know to where you go and how to drive, you use enemies that basically everywhere around will kill you. That's the main problem with the cyber. No matter which tools you have, it does matter who you are, how you can stand with these tools and use these tools and basically do something in the world because the other world, the other part of the world is very, very aggressive. And that's, that's the reality.

Welcome to Unspoken Security, the raw and gritty podcast for security professionals who are looking to understand the most important issues related to making the world a safer place, including intelligence-driven security, risks and threats in the digital and physical world, and discussions related to corporate culture, leadership, and how world events impact all of us on and off our keyboards. In each episode, host AJ Nash engages with a range of industry experts to dissect current trends, share practical insights, and address the blunt truths surrounding all aspects of the security industry.

<LYRICS>Decisions are made.</LYRICS> Hello and welcome to another episode of Unspoken Security. I'm your host, AJ Nash. I spent 19 years in the intelligence community, mostly at NSA. I've been building and maturing intelligence programs in the private sector for about 9 years. I'm passionate about intelligence, security, public speaking, mentoring, and teaching. I also have a master's degree in organizational leadership from Gonzaga University. Go Zags! And I continue to be deeply committed to servant leadership. Now, this podcast brings all these elements together with some incredible guests to have authentic, unfiltered conversations on a wide range of challenging topics. It's not your typical podcast. It's not all polished and put together necessarily. Sometimes my dog makes appearances. I don't think we'll be graced with one of them today, but you'll see. People argue here and we debate. We even swear sometimes, and that's all okay. I want you to think of this podcast as a conversation you'd overhear at a bar after a long day at one of the larger cybersecurity conferences. These are the conversations we usually have when nobody's listening. Now today, I don't think we're going to have quite as rowdy a conversation. I don't think there's going to be a lot of swearing going on necessarily. We're gonna have a more of a technical conversation today because I'm joined by Ivan Novikov, who's the CEO of API and AI security company Wallarm. He's got over a decade of experience in cybersecurity, well-versed in system engineering, security analysis, and solutions architecture, possesses comprehensive understanding of various operating systems, programming languages, and database management. And his expertise extends to scripting, DevOps, and web development, which makes him a really versatile and highly skilled individual in our field. And he's worked with top tech companies such as Google, Facebook, and Twitter. He even spoke at Black Hat. Ivan, anything you want to add to that?

Uh, no, I guess, I guess you covered them, you covered them all. Thank you. I never expected that much, to be honest.

It's not a problem. Your people, I think, gave me a pretty good bio to work with. So I can't take all the credit. You've got some folks and they gave me some stuff to work with. So listen, today's topic is a really interesting one. I'm sure it's, uh, it's brought some people's attention at least. Because today the topic is they're hacking the people. Now it's like, it's an eye-catcher for sure. It gets people's attention, but I'm not sure exactly what we're gonna talk about here. I have a fair idea because you and I have prepped, but the crowd doesn't know yet anyway. So we're not talking about hacking people directly necessarily. It's, you wanna talk about androids or, or the future of, you know, the combining robotics and humans. But as I mentioned in the opening, your company Wallarm, it's API security and AI security is really what you're focused on. So I think what we're gonna talk about today really is more of the API security piece. So, Let's set the baseline here. What's been the traditional way to approach API security?

Oh, that's a good question though. So first of all, we have to define what the tradition is, right? And when it started. I guess that, and I started as an SAP guy, so I spent a few years with SAP Enterprise Service Bus product called SAP PI. So that time, and it was like a couple of decades ago, I think, API was always about connecting different systems, mainly API security at that time was all about how to make a kind of gateway behind this two to make sure that we have enough of controls, but that time APIs by design never were designed to be exposed or used publicly. However, it changed, so API security significantly changed since that time. Mainly because of the two things. The first of all is mobile apps and, you know, all of this iPhone-driven, you know, smartphones everywhere. New era actually of these apps, all of them driven by APIs, right? There's mobile devices always using API on the backend with, you know, some frontends called apps, right? And then, and then by, by new technologies such as connected vehicles, connected cars, connected pretty much everything, IoT in general, things, smart cities, and so on. And in terms of the web, like a website that we visit on daily, it was also the transformation that actually caused by the technology called SPA or single page apps, where the frontend and backend were actually completely separated. And because of that, we do have the API in the backend, even if it's just like simple web page. So APIs now everywhere. So what changed in the approach of the security, the threat surface, right? The attack surface became much, much larger and APIs itself became more and more publicly available rather than it was before. But all the previous legacy APIs is still there, right? Specifically in enterprise world, they're not gone, just, you know, hidden deeply inside. On the top of that, we have more and more APIs and they all interconnect to each other. And most recently, probably this year, we'll see the third wave of transformation of those, mainly caused by AGI and agents that actually consume APIs. So if to simplify what the traditional approach is, we have to identify from where we count. If we count 20 years ago, then API became more and more publicly available. And because of that, you know, new controls, actually new requirements were raised. If to count next-gen and basically what happened last 6 months, then we mainly talking about expansion of this agenda, KI and risks, and at the same time API security controls, right? Align to these new risks caused mainly by AI consumes APIs.

Well, I certainly started playing with some of that myself, right? I'm starting to play with some of the AI bots and tools because everybody sort of has to. It doesn't take long if you play with these before you realize, boy, I really could use some APIs on some of this stuff. If I really wanna get the data to work the way I need it to, I want to ingest what I need. I need, I need these, you know, AI bots to be able to do things without me having to go fetch everything. You very rapidly realize you gotta get very smart for this stuff, which I'm not, by the way. So, you know, it's a bit of a challenge to start working through it. But, you know, talk a little bit about, so we talked about the market, obviously it changed. You said, you know, obviously with mobile, for instance, coming in and, and some of the changes to, to how web was designed. APIs that used to be not meant for public consumption and now they're everywhere, right? Everybody who works with computers knows how to get a hold of an API for a feed for just about anything. But do you want to talk at all about, you know, what we're doing in terms of detection of attacks, right? How much has that changed? What's the baseline been? And then we'll talk a little bit about what's different these days.

And by the way, I caught you because you said that you played with AI bots rather than AI agents. And that made our discussion very interesting point because Bots itself is a very interesting angle and it's a very interesting task for cybersecurity nowadays. Ultimately, we're talking about good and bad bots everywhere and there is nothing like, you know, only bad bots as it was before. So getting back to your question though, technology-wise, just a few things, right? The API security in the pre-massive web, SPA, mobile app, and IoT era, basically before 2016 plus, mainly were kind of like very similar to firewall task where you basically isolate and apply controls, mainly access controls and nothing more. And technologies that, you know, use there mainly were built by, as I said before, Gateways or the technologies to basically designed to mainly authenticate and authorize access rather than dig into the data. Then it changed and It turned over to the data analysis and the usual approach to block attacks in data always was just signatures. However, it doesn't work, at least web signatures in general sense doesn't work for APIs efficiently. The technology we built never even rely on the signatures or regex, regular expressions in common sense. We instantly realized that by default, we only will produce false positive for APIs. So we start to reinvent this and we build what we called real-time API data decompiler. So basically we decode data formats like JSON, Base64 inside, and XML inside if needed, any nested levels of those, and then decoding the data structures itself. Let's say if it's just a sentence or credit card data or some, you know, text data, we actually decode it in the right way by by using technologies that nowadays pretty much everyone is aware. It's called tokenization. But 2015, 2016, people just ask us, hey, is it anyhow better than regex? And now we have an answer. Look at this GPT, you know, it's much better, right? So that allow us to build a tool that can detect attacks in real time in any, you know, sophisticated complex data structures, and many of them actually in real time nested. And that, that was a fundamental shift. Nowadays, the same problem even more important because we not only have issues with data itself, but also behavioral problems related to, as we discussed before, some good bots or automation tools or APIs by default designed to use by automation tools such as your partners or some, you know, customer bots or your export and import controls, right, that you basically doing by default at scale. So that all stuff multiplied the problem of only data control to also behavioral control, which we called API abuse. And by default, it meant just, you know, some unusual use cases for APIs. But in fact, it's much more broader than this. But that's a short overview of the technology kind of like evolution for the last 10 years, I think.

Hmm. Well, and, and there were some challenges, obviously, and some gaps from the security standpoint, right? So, you know, you had some understandings of how this worked. Now, there weren't a lot of API incidents or detections of, of data breaches, at least publicly known, but I'm, I'm going to gamble maybe that's because, that doesn't mean they didn't exist, just because there weren't detections, right? That it might be hard to, to identify some of those things. But, you know, there were, there weren't a lot of new products, which is not a bad thing, I guess, but there also wasn't a lot of new protocol. But then, like you said, you were sort of stuck with behavioral analysis, which makes it difficult for discovery. You know, were there more missed attacks? Obviously, we're gonna talk about the future and where you are now and what you're doing differently, but it's nice to know what the challenge is that we're solving for, which I'm, I'm gonna go ahead and kind of guess at this point, it was a lot of missed attacks and a lot of missed things. Aside from the evolution you talked about of just the, the technology changing in a whole, you know, was the security part of the problem that led to you wanting to go a different direction?

Sure. And then first of all, I a little bit disagree with you about the data breaches that publicly known. We track them quarterly for the last 3 years. Every single quarter, Voluum released the threat stats report, API threat stats report. And last couple of years, we start to also track data breaches itself, not only CVE and vulnerabilities. And the reality is every single quarter, we actually faced with roughly 10 public publicly available incidents related to, and actually data breaches related to API security directly, and we only count the right path, and I'm talking about companies such as Dell, I'm talking about companies such as, you know, like pretty much large companies like Samsung and others, so this all happened about them very, very often, and I think that the overall data breach attribution is a kind of like unclear thing, right, and if it's not brand than you probably didn't know. However, with APIs, it became more and more common now to directly point what's going on because in this, at least in this, in the postmortems or any public announcements from the vulnerable vendors like victims that we see more and more APIs directly or indirectly involved. So we know that they were involved and we can attribute by this. It happened very, very often. So it's, it's definitely there. The other thing that pushed us to that direction actually was the customers itself, right? Even not amount of data breaches, as I said before, we only start to track vulnerability CVEs and reports about API security and API issues quite 3 years ago and we built product roughly 5. So 2 years we mainly rely on the customer needs and customers, they already know what to do because in reality, if you're talking about like large enterprise company, you do have a lot of different controls, not all of them placed together. Some of them just, you know, last mile controls such as your SIEM or some unexpected behavior and ransomware. And we learned that if majority of the real incidents, let's say cryptors or crypto miners, like caused by actual backend exploit, definitely customers realize it, they have them, right? Because it's CPU usage or memory usage, they caught them and they blocked them and they realized that the initial point of penetration was API, right? And that's how we learn more and more use cases from real time. That's from where we start to do. And, uh, that's, that's the reality. And you also have to think about amount of products, like enterprise products specifically, that use APIs and use an API. And I can recall to the most recent issues with Palo Alto devices, Fortinet devices, and many other network devices, actually access control devices, right? And majority of these issues, if we only count critical issues, you know, remote access control and so, majority of them caused by APIs. And we're not talking about some modern APIs. Many of them used SOAP and some, some stuff from last century, essentially. But it, it is the case. And think about this, cyber vendors that you rely on for your front access, right? And access control vulnerable itself. I'm talking about VPN devices. I'm, you know, border control devices, firewalls and different kinds of them, majority of these issues are related to APIs and it's just basically one touch to your network, right?

That's scary. Yeah, exactly. I mean, it is. And people trust these things, right? I mean, there's, there's a lot of very quick, I need this, it attaches to that, let's go grab it. People trust APIs without a lot of thinking or testing in a lot of cases because it gets you what you need. You know, Bruce, it boosts, you know, connects systems and moves data around, right? And so, yeah, it's, uh, it's not necessarily, I mean, you're like, I think your security organizations already check them out, et cetera. But if there's a compromise, I think a lot of people don't necessarily know that until it's going to be too late. It's funny. I'm going to go back real quick just because you had mentioned, you know, the fact that I referenced bots versus agents. So, and, and it's a good point. I don't know if I'm using the right terminology, if I'm being honest. In my head, I've, I've split the line as if I'm interacting with it, it's a bot. If it's doing things on its own, it's an agent. That's just sort of where I've chosen to draw the line in my own head. When people talk about like agentic, I'm like, until I can just give it instructions and go away and I, and I come back and things are done, that to me is an agent. Which again, this may be wrong. I'm not here to define the industry. I'm just doing it my way. But I think of an agent as that's like having an employee, right? You can tell somebody, hey, I need you to do this thing, or you can ask them to do a thing and then you walk away and you come back and they've done the thing. That's agentic. If I'm standing, well, sitting, if I'm sitting out in front of my computer and I'm talking to this You know, AI, and I'm saying I need this and it does it. And then I say, okay, now I need this and it does. And if I'm directing it all the way through and changing the instructions as I go and making all these adjustments, to me, I, I just consider that a bot still. Now again, there's no guarantee that that's the right language. It's probably the wrong language. I'm sure there's a bunch of AI experts that are cringing if they're, if they're listening right now. And to be honest, I don't care. So, you know, they cringe all they want. It's the, the terminology I've used for myself so far. I'm sure I'll get bullied into whatever the vernacular is for everybody. But until something does it on its own, I guess I've steered clear of calling it agentic. Otherwise, I'm not really sure what the difference is between that. I don't know how they're not all agentic, I guess, at that point. If I'm telling it to do something and it does it, and then I have to tell it iteratively to keep doing it, and that's agentic, then I'm not sure how you name the thing that's auto— I guess it'd be autonomous agentic or something is what we'll come up with next. But I've got all the terminology I need. So, so for me, it's bots and agents will be things that are coming soon that'll do on do on their own with what I've had to teach the bots how to do, I guess. So, all right. So getting back to the topic though. So there is a lot of, of danger and risk with the APIs. They're, they're prolific. You know, this, this is a technology that most companies depend on. A lot of individuals depend on it, but certainly most companies depend on this to, to connect systems. So I don't normally do things this way with the show. This is kind of a rare exception where I'm, I'm actually really interested in your company specifically and what you guys are doing. I don't normally do that. And for anybody who's wondering, no, you know, I didn't pay to be here. This isn't a plug. It just happens to be the way the tech works. It makes more sense to really talk about, hey, what are you doing specifically? Right? So, so that's really the question. Like, what are you doing differently, you know, with LawArm and why are you doing it differently? What's the reason for somebody to go, oh, these guys are onto something, you know, as opposed to what's been going on in the past?

Yeah, that, that, that's a good question. So that's, that, that's a really good question. So I have to think about this a little bit more. I think to transfer in real time. But in fact, forget about what I can explain you, right? And if just to look at the customer use cases and what they're looking for in reality, right? There is actually two things that we can use to, you know, split the cybersecurity industry in general by different buckets. It's a compliance bucket. Where you need to buy because you need, right? And there is a regulator or someone who push you to do so. It might be your customers, it could be the government agency, whatever it is, right? And the second bucket in cyber is actually threat prevention, right? Prevent threats. And if you cannot prevent the threat itself, still prevent the damage of the threat, right? That's all the second bucket. So we play in the second bucket with the threat prevention things. And now we're talking about threats, which API threats the most common and the most known by customers. Ultimately, it's still too early to say because API security as an industry at the beginning of the journey and majority of the use cases usually start with basic things such as assessment, show me what I have, so-called API discovery and so, which became more and more commodity and available pretty much everyone. However, API threats is very, very unique and some of them very tricky. And then we are really good in identifying these threats and help customers to actually block them, even know that they have this threat. I mean, real attacks, real exploits, real, you know, scary thing that you cannot tell no for. That's my criteria of success, right? Because customers usually don't want to buy cyber, right? And they looking for every single reason to don't do so ultimately because cyber is still a cost center and it's not producing revenue itself. So our job is to find actual threats that real, applicable for them and definitely impactful enough to don't let them say no, right? Because they ultimately have a bunch of reasons to say no, right? In many cases. And nowadays it happened with the API. Why? That's a really good question. First of all, we now, as I said before, I guess somewhere at the third wave of the technological shift from this mobile adoption to cloud adoption and then AI. Adoption in general, right? We do have a lot of, and ultimately agents nowadays, the most greatest consumers of APIs and customers interested to, you know, again, find out what's going on with them, how big is the potential impact, how they're vulnerable, what's the risk and how to then map this best case to also stop threats and the difference between this evolution and all the previous waves as, and I'm really sorry for the broader answer, but I guess it's very important. Try to unpack it in full as think about that. It was never happened before in a, you know, modern computer history when adoption of technology that fast and that, you know, massive, let's say enterprise adoption for, you know, actual AI enterprise adoption nowadays is much wider than cloud adoption. So cloud's there for 20 years or so. Enterprises still play around and tell, hey, I'm not sure if I need this or that. They still choosing multiple vendors. They still have data centers and some dedicated servers for different needs, but AI is everywhere already and no one say no, right? That's a fundamental shift from companies who against cloud, right? By default, let's say all of this from government agencies specifically overseas, right? To large enterprise companies here in the States, they all with AI regardless of their relations to the cloud and that never happened before, right? That's why this AI already drive this adoption and threat landscape, right? And that's what makes at the end of the day our offer aligned to the customer needs and also product unique.

Yeah, okay, well, I mean, that makes sense, right? And it is interesting, you know, I was actually, thinking about some of the stuff we had prepped for and, and just some of the technical components. Now, I don't normally go in the deep technical stuff. I normally leave that to other people, but in this case, I, I found it pretty interesting because I, we had talked previously about, you know, API protocol parsers and, and how hard it is to set up this, this real-time near-zero latency approach, which, which from what I understand was really the foundation of what you were trying to build at the beginning here, because latency is a, is a problem. Obviously the longer it takes, the worse things are. So, You know, I, I don't know if you can dig into that a little bit more, talk about that, talk a little bit about how you moved into the ATT&CK payloads and doing some parsing in that space and some of the real deeper components to this. I don't know how much that you want to share. I guess maybe it was, it's, it's, I would say it's off the record, but it's not off the record. It's written down for me at least. So I don't know how much you want to go into the depth of, of how that was all built out and, and, you know, your thoughts on regex for that matter, which used to be kind of a standard.

Yeah. And the regex is, is something that I really like to talk about. First of all, because people still rely on them and somehow You know, there is a kind of the general sense that it's somehow working, but in fact it's just broken by default. And just a few things, like when we build something, right, there is a model, usually it's some sort of scientific model, best case very strict math that you can apply and then, you know, find out if you're in the right way or not, right? And it also, also important because you will know all your limitations and out of scope thing that bow behind your model, right? So we did the same for ABA attacks and we instantly find out that there are the signs about the grammars of protocols of parsers by the guy called the Noam Chomsky. He's still active, by the way, where he—

Oh, sure. Noam Chomsky.

Yeah. And Noam introduced a lot of different things from, you know, biology to genetic science to finally theory of compilers. And he's the guy who basically invented compiler in general sense, right? And he introduced what's called Chomsky grammars hierarchy. So in there, you can find out how the different languages are different, right? Regular expression, by the way, covers only regular syntaxes, right? In reality, data and data flows and the parsers you mentioned before, just API by default and the data's there. It's not something that you can cover by any regular grammar by default because it's way behind it. It's more basically recurrent defined or even Turing machines. So if not to dig into this, let's say you cannot, if your object is a little bit bigger than your box, you cannot put it inside, right? The same as here. So the hierarchy and the syntax we wanna, the grammar itself, right? That we want to protect a little bit more complex than regular expression can cover. And because of that, you have to extend this regular grammar to cover more cases. And because of that, you will have a lot of false positives by default. And, you know, you can think about SQL. I assume that it's a very known common database syntax, and you have some keywords such as UNION and SELECT. And if you imagine that you have a regex for this, you will never ever be able to build a regex that will cover properly all the variations of the SQL, because SQL by default is not SQL is not regular grammar. So there is no regex in the world that can completely cover SQL, right? To avoid that and make the detection fast, companies usually apply very similar technologies to WAF, web application firewalls, or regex-driven detects when you have some sort of the signature like unions and select, and altogether it works like just a regular syntax that cause some false positive around and this thing will not check the syntax in full, right? Just catch a piece of them and block. And instead of doing this, we just decompile the full string to tokens and find out how tokens relate to each other and apply right, actually finite state machine that it's more close to the real syntax and we then can make sure that we know everything. That's the first thing. But in reality, grammars are not plain and you will never see just SQL in a field. In, in general sense, you have cases such as Open Banking API where you have a JSON with a Base64 field inside called payload. And inside this payload, in many cases, you will see an XML document and inside of XML document, you'll see something else. So even cases like that, just absolutely unbreakable for regex and you have to apply parsers, but your tool. Should know how and which process should be applied. So we crack the problem and we build a tool that actually can decode that complicated data formats in real time. And that's, it's very important problem. And that, that's how we actually approach the API security in general. And we never did regex at all. So it doesn't work this way.

Well, that sounds like what you're saying is that's, I mean, that's the special sauce, right? That's what makes you different or better or Yeah, better, I guess, would be the word to go for, right? That you're able to, to dig into this and look for the payload if there is one, right? So then you can determine if this is something that's malicious or if it's benign, right? If it's, if it's what it's supposed to be versus if it's been injected with some sort of malicious code, that would be a problem. It sounds like that's, that's the, the key component you're talking about. Now, is that, I don't want to put you on the spot, but I'm going to, I guess. Is that unique to Wallarm? Is this, is this, uh, are there multiple companies that are running the same concept and the same technology? Or is this, are you guys the first to the field with this? Is this a patented approach or is it just a matter of doing it, you know, better, faster, cheaper, better service kind of a thing?

No, as I understand, we are the first and the only, and we have a patent for that. But in fact, again, there's different ways how to approach the same problem, right? Some of the companies try to build whitelist, like basically allowlist patterns instead of like the compiler sums and only will pass through this. And we also have that stuff as an additional level of control. But in terms of the real-time, the compiler, I don't thing that someone needed. And it's hard, to be honest. It's like a lot of— it really is the same work as to build the compiler or many different syntaxes, but you have to be inline, means you have to be fast, as fast as hell, right? And it's linear complexity problems that you have to achieve. And also you cannot consume a lot of resources. Ultimately, it's a common problem in compute, right? You definitely can be faster, but you will consume a lot of resources. So definitely for us, it's the same, right? We consume CPU and because of that, we can deliver near zero latency. And definitely RAM is also involved, but it's not free, right? And then the goal was to also make it fast and predictable by resource consumption.

And yeah, I think— So you're the only ones that are decompiling payloads, like, in route with the API. And I mean, that's impressive in and of itself, that you're the only ones doing it. So what— I think I know the answer to this, I guess, you know, the advantage that creates versus the rest of the industry. So I guess I'm going to leave that one alone for Max.

I think you've already covered it.

Let's talk about something else in this. So what, how long have you been doing this? Like, so you, you've, I mean, you've changed API security, right? You're the only ones with the decompiler that can actually investigate and interrogate the payload directly in this fashion. How long have you been, have you guys been doing this? Did you, are you just out of stealth? Are you, are you new to the market right now? How long, how long has Wallarm been out here?

That's a good question. And that actually took a lot of time. So we spent roughly 2 years in a stealth mode by just, you know, polishing technology before official release. And we started sales back in end of 2016 after the Y Combinator Inception program in Silicon Valley. So it was just an official start. And since that time, we're constantly involved in product, changing it and more features. But it took a lot of time and I'm still very glad that we still have the same engine or at least the same core engine that still worked for all of the years. But it took a lot of time. And also it's very important to mention that when we initially started, the complexity of API protocols and use cases were not that broad. Now we have new use cases coming because of AI, because of some, some, you know, IoT and some other new technologies. And it was not there, right? We always have to add some new protocols and adjust the way how we decompile it, but the general sense and the general logic is still the same.

Well, that, I mean, that brings up another good question, I guess, with AI and all the, the changes that do come along with that. Is this, are you evolving to meet that? Is, is, are you already in a position where as these things are developing, how different is it, right? How is, and when you talk about, you know, agentic AI and, and how that's interacting with the, you know, the APIs, how different is that from what you've seen previously and how much of an adaptation are you having to make and how much is the rest of the market having to adapt to it?

Yeah, look, I cannot tell you about, you know, the rest of the market in general sense, just like it's a bunch of different new things that happen, but I think that what we can point at this time is AppSec. What you're asking about is like how, what this API security in general, how it's transformed, right? In fact, we still playing the same application security as, you know, decades ago. It's new use cases for them and just in general sense, API by default, it's just an interface, right? It's an interface to the application business logic. So when we're talking about API security, it's a part of AppSec and we're talking about real protection for the business logic of this, of this applications, right? And the API is just an interface, much faster interface, right? Much more, you know, agentic and robotic friendly, much more automation friendly, less human readable, but it just an interface, right? The same interface HTML was with CGI like decades ago, right? It is a new interface. And then agents come to play. So agents from one hand, consumers for API. So basically agents need some data to proceed and they need to do some actions. Actions happen in application business logic. The way how they iterate with applications, right? How they already doing something and interact with that is an API. So API is an interface between this agents or robots and application business logic. However, this robot itself or agents itself, they also application. So they have their own internal APIs, right? It's very similar as, you know, you think about the biology of human being and like all the other creatures, we're all built from the same cells, right? And the cells somehow communicate to each other via some sort of, you know, signals and different, you know, ions and molecules. So it's the same as API. API is an interface. What's inside the cell is always the same. And now we can combine many different pieces of them to get some more sophisticated agent, which I agree with you should be somehow, you know, at least automated, if not completely autonomous. And that makes them different from bots, for instance, but that's the thing. And that's, yeah, that's probably it.

That makes sense. And there, and that's, I mean, that's the future, right? This is, we're just gonna see more and more of this, obviously, you know, AI is As you said, the adoption rate's really high already, you know, and, and the potential is incredible. I think there's a lot of risk that goes along with it right now, and there's a lot we don't know and a little concerned at how rapidly we seem to be adopting and just sort of handing over responsibilities to, to AI bots, agents, whatever terminology you want to use. But it's also gonna create a lot of new security concerns, right? And, and figuring out how, how things are interacting. And as those change, you know, it's good to have somebody like you and your team that seems to be ahead of it a little bit to understand, you know, what these are gonna mean because AI is not going anywhere. And frankly, APIs aren't going anywhere either. Like, there's still a huge part of how everything works together, at least for now. I don't know, maybe eventually AI will supersede it and, and be everything. But right now, APIs, I think, are, are a big part of this. So, I mean, we're coming up on time here, so I do want to get into the closing question for the show, right? So, you know, the name of the show is Unspoken Security, and everybody gets asked the same question. And we get a lot of different answers here. Some, some are very work-oriented and some are, are not. Some people have made all sorts of confessions. Please don't confess to a crime or anything. But with the name of the show being Unspoken Security, the question is, tell me something you've never told anyone before, something unspoken.

That's, that's a very good question. I have a few, a few answers for this, to be honest.

Sure.

But my, my short answer, my, my short idea was to explain that against the, the marketing hype, right? Many of the old-fashioned controls in cybersecurity, included by the way web application firewall that we explained before, might be very useful and efficient for API security. So in other words, when you invented something new, even this AI agents and so, it doesn't mean that all the previous security control doesn't work. It means that your threat landscape is a little bit more or not a little bit like crazy expanded, but previous controls should be applied. And I guess that what all the vendors try to kind of let you think about rather than tell you the ground truth, the ground truth as whatever you have in place in terms of your security controls, specifically related to new technologies such as AI, or it happened with cloud before, right? They all work. You just need to polish them and apply and implement. And you always between two choices to try to adjust, adopt, and, you know, somehow align this old tech or old products to your new tech or buy new products, but it always a choose, right? In our case, for instance, it means that yes, you probably can try to play with regex and apply new controls and create these rules, but it will require you to play days and nights with those rules and in fact you have to, you know, implement as many rules as you have parameters per each endpoint, you have 100 endpoints, 10 parameters each is just 1,000 rules, but this is possible and that's the thing, right? It's not completely not related, right? So we were always playing with this and the same with AI, right? Let's say if you have a simple proxy and you can route the AI traffic through a simple open source proxy, you still can apply a lot of controls and make a lot of value. This, right? And if you really know what you're doing, you can achieve much more than just like trying to blindly buy products and push them together in the stack. And that's the reality. It's the same open source, but it's a little bit different angle. But in fact, I guess that's what I have to fairly accept and share with a broader audience. There is always something that you can use to make some new fancy security stack, even for new use cases such as AI. Because at the end of the day, all of this LLMs, GPT, and so they still consuming some old and known technologies under the hood, right? And we, we know how to secure them, we know how to approach them, we know how to build threat model for that. And yeah, that's, you know, that's the truth.

Well, it's probably not the, the best businessman type of an answer to say, hey, we've invented this new thing. By the way, you keep using all the old stuff, it still works. But I, you know, I appreciate the honesty. But also, I mean, you make a valuable point in that Yeah, it still works, but it takes a lot of effort, you know, and it's hard. And that's, I mean, that is the point of a lot of technologies. Just because something new comes out doesn't necessarily mean what we have is, is no longer useful. It's just not as good. And that's why we end up evolving to new technologies. When cars came out, it's not as though horses wouldn't get you from A to B anymore, but I don't think people are going to stick with horses any longer because, you know, it's, it's, it's a lot slower ride and there's a lot of different maintenance to it. And as automatic transmissions showed up, a lot of people still drive manuals, of course, of course. Some do it for fun, but the automatic's a lot easier. You know, if you live in a town, you live in a city, do a lot of rush hour, or you do, you know, you have a lot of hills or mountains or whatever, you probably have moved on to an automatic transmission. So just because the technology is still useful and can be used doesn't necessarily mean it will be. And it's certainly, you know, if somebody makes something that's better, faster, cheaper, that's sort of the way you go. Not necessarily cheaper at first, but better, faster, cheaper, efficient. People evolve just because the other thing exists. I've, I've seen that, you know, in the threat intel space. I've worked with, you know, organizations where it's like, well, you can, you can buy this threat intel platform and it's free. They don't buy it, but yeah, it's free, but it comes with an awful lot of effort. You know, now I need, now I need an engineering team and I need to really manipulate this. I need to have somebody work on it where I can pay somebody and that solves that problem for me. And that system's a better system and it's better organized and it's maintained, et cetera. You know, so there's, there's trade-offs that come with it. So, uh, I, I appreciate your candor and honesty to say, listen, you don't have to rush to do this necessarily. What you have will work, but it doesn't sound like it's gonna work very well, frankly. It sounds like it's gonna be hard and isn't gonna work nearly as well as what you've created. And it's gonna create more risk for you as a result. Like you said, you have a very large threat surface if you're using a lot of APIs, which everybody is, and you're probably gonna miss a lot of things. That was a reason, you know, that these things have evolved is, is using the old system is a lot of time. It's a lot of effort. And it's comparatively sloppy, I guess, in terms of, of its security. So I think that's something where somebody can sit down and do a POC and decide for themselves, you know, where the value is. Hey, how much time and money and energy am I going to save by not having people have to work on this stuff? How much safer am I going to be? I'm sure somebody can do calculations. I'm sure you have people who've done it in sales, in their pricing department to decide how to make it look like this pays for itself. And maybe it does from what you're saying. It's, it sounds like it's a pretty good leap forward. So, so anyway, I think it's really interesting. I appreciate you coming on to talk. About it. If anybody wants to know more about Wallarm, feel free to reach out. The information I'm sure will be available in the show notes, but you can also reach out to myself or Ivan to learn more about it. It's, it's an interesting technology. As most people know, this isn't my strength. I'm an Intel guy. When we get more technical, I tend to have a stronger leaning on the customer or on the guest to have the discussion because it's not necessarily my strength. But I did find this interesting, especially when you get into the discussions about, you know, the interrogation of the API itself and the payload and being the only organization that does that., you know, is special. You know, I don't know how long you're gonna have that market advantage. I'm sure people are gonna find a way to copycat, although you said you have a patent, so that I assume will help, but I'm sure people will find different ways. But at least right now it sounds like you guys have the lead space in the market and it's a, it's a big market. A lot of people have APIs. So anything you want to add as we close out the show or anything you missed? Any, any last thoughts, any, any advice, any jokes, whatever you might have before we close out the show?

Uh, look, it's, it's, it's a really bad joke, I think. But when, when you said that the analogy between the manual transmission and automatic transmission, right? A horse versus cars, the fundamental thing like roads never changed, right? And in other words, when you're driving your car, right, there is not that many enemies who want to kill you, right? In cyber world, it's completely opposite. No matter which car you're driving, if you don't really know to where you go and how to drive, you use enemies, it's basically everywhere around will kill you. That's a main problem with the cyber. No matter which tools you have, it doesn't matter who you are. How you can stand with these tools and use these tools and basically do something in the world because the other world, you know, the, the other part of the world is very, very aggressive. And that's, that's the reality. And unfortunately or fortunately, right, for, for us as an industry, right, as a business in cyber, it always not enough. So it's absolutely, whoever you are, you still have a risk of data breach and you will have more and more risks exposed every single day with different things. And you probably, knows there's something like that. You really don't have a lot of, you know, a lot of space for the mistake. You probably should be better in everything and your team should do all the good job. And the other side, attackers, they should have to, you know, be lucky just once, right? And that's fundamental shift, the fundamental difference between driving cars and horses versus what do we face in the cyber. And that's probably that from my side.

No, it's a good point. I mean, yes, Rarely to my knowledge do people shoot at me while I'm in the car. If they are, they're, they're not hitting me at least. So yeah, right. In the same cyberspace, there's a lot more risk. There's a lot more hostile activity. And yeah, we need to be as good as possible. And as you said, we have to be right all the time. The adversary only has to get it right once. We used to talk about that a lot in counterterrorism when I was in the, in the government space. It's the same thing. You can stop all these terrorist attacks, but the one that gets through is the one people are going to know about. And cybersecurity professionals live that life every day, basically. So another good reason to take a look at something like this, even if the old tech might work, the faster you can get technology on board that'll take these problems away, that'll make you more efficient and more effective. It sounds like it's probably a worthy investment to take a look at because this is, this is a huge challenge to deal with all the API security that goes along with it. So, all right, with that, listen, I'm going to wrap up the show for today. Again, Ivan Novikov, thank you very much for joining me. If anybody wants to know more about Wallarm, reach out to him or myself and I'm happy to have that discussion. Pass things along for you. Otherwise, uh, we're going to go ahead and wrap it up here. So this has been another episode of Unspoken Security.

That's a wrap for this episode of Unspoken Security. If you enjoyed this episode, follow us wherever you listen to your favorite podcasts. See you next time.