What is "True" Attack Surface Management (ASM)? - Surfacing Security Ep 4

MG:
maybe a good thing to talk about is ASM, because I think there's a lot of, I guess, variability, let's put it that way, and what people, you know, say is ASM, what people are marketing is ASM, what buyers think is ASM, what analysts firms are putting out as ASM. And I think it's very confusing at the end of the day for a lot of buyers. And, you know, as a company who's been doing this for a very long time and who was sort of at the pioneering side of this, I think, you know, it might be a good topic to kind of discuss how we think about ASM. And I think, you know, maybe perhaps the key distinction with how we think about ASM is that it's less of a, uh, less of a tool per se, and more of a way of doing things and more way of thinking about things, more of a practice, like at the end of the day, um, it's about how do you, how do you manage exposure in a modern attack surface and, and what that looks like. And, and, you know, how we approached it was just simply that at the time when we started, the ways of doing that weren't ideal, right? It wasn't really keeping up with the way that the way that things were evolving. And so that was really the genesis of, of, you know, Asinote, but ASM as well, where it's like, you know, we need to, you know, there is a better way to do this, I think, less, less focused specifically on the tooling and more just about, you know, the core principles and the ideas. And, you know, from my perspective, I think the core principles have always been like, you know, asset awareness and visibility as a key. Speed, you know, it has to be real-time or as close to as possible. And signal and scale are probably other sort of key pillars of it as well. But then also the core principle of asset discovery is not the end, right? It's not the end result. It's not the outcome that people want. It's what they do with those assets and what they do with that visibility that really matters. And that's sort of been our focus. But I don't know, do you think there's anything more to it, you know, from your perspective?

Shubs: No, I think you've got some really good points there. I mean, that's how I see ASM as well. And I think there's a story that kind of encompasses what we do as an ASM company that I get reminded of all the time. I was a consultant, and I was on a red team. And I remember there was this really big US company that had just been breached. And we were on this red team, and there was quite a lot of pressure to find stuff on this engagement. And I remember thinking back then, and obviously this is long before ASM was a thing, and this is long before we had even built Asset Note. But I remember thinking back then, like, we need to be able to capture everything that's going on in this attack surface, like new ports that come up, new changes, new technologies, anything that we can identify that's going to lead to some level of ability to exploit something. And I remember back then, my manager at the time was like, yeah, that's a really good point. We've got to do that. But how are you going to do that? There was no ASM at the time, really. And the way I see it is what we've been building is this, what you said earlier, asset awareness of when things do change, when things do come online, come offline. And that's where one of the things that you also said to the speed and scalability is very important. So we can actually cover these things across a large attack surface. And then obviously, the exposure monitoring side, which is going that one step further, and actually understanding the real exploitability of issues, which is what I think is a very important thing when we talk about ASM, that we kind of understand as, as, as like a very important part of ASM, whereas other potentially other ASM vendors don't go to that extent when it comes to proving the exploitability of issues. But But yeah, I think for me at that point, it kind of solidified my view of ASM as something where, you know, we in an automated way need to understand exactly what's happening on an attack surface and be able to operationalize that in order to find exposures on the attack surface in a very scalable, reliable way. And that's kind of what we've been working on ever since we started AssetNote.

MG: Yeah, I think from my perspective, the interesting part of this is that when you talk about ASM, a lot of it seems really obvious and fundamental, and it is fundamental, but I think the key point to remember is that IT security doesn't exist in a vacuum, right? It's a function of the broader IT environment. And so when you say like, hey, you know, like, yes, everybody needs to know what they're trying to protect. I mean, it's that sort of statement gets thrown out there, right? But if you think about it in a modern sense, and in the larger IT context, you know, that's a lot different to answer that question today. Like, what am I protecting than it was 10, 15, 20 years ago? And I think that's sort of, you know, the key point about why it needed to be different. Because if you think about that larger IT environment, you know, what are the trends that you've seen, right? You see cloud-native architectures, cloud-first architectures become the norm and, you know, a lot of migration away from on-prem. heavier use of sass. this sort of breaking down of the perimeter in a traditional sense, right? In a traditional infrastructure sense. The rise of DevOps and sort of rapid and continuous deployment and sort of this idea that you sort of essentially develop in production in a lot of ways, like the move fast and break things. And so if these are all the trends that are going on, it actually makes something as baseline as understanding what you're trying to protect actually quite difficult. and quite an interesting problem to solve. But I guess the other point of it, and you touched on it a little bit with the exposure side, is from our perspective, one of the core ideas was always, as I said earlier, it's never about just getting a list of assets. That's one part and that's a core part because you have to build on it. you know, the idea that people want to do something with this. They want to run a vulnerability scan or see the exposures. They want to understand, you know, marry that up with their threat intelligence or other things like that. It's like they want to do something with it. And that's really the core idea. And, and, you know, and that's sort of, you know, where we've we've focused, you know, when we started, there were a lot of companies, and really, to be honest, a lot of companies still today that try and focus on integration for that, right? In a couple of different ways. One is they are doing discovery. And then they'll say, yeah, like, just pipe it to some vulnerability scanner. And then you've got you've got, you know, vulnerability scans. And, and, you know, others will do it from a different direction, you know, and the more the dashboard sort of companies, I guess, the chasm style companies, right, that will take integration in, and then try and marry it up with other data sources that they've taken in. and provide that sort of dashboard view. And one of the problems with that, at least from our perspective and our sort of philosophy is that it wasn't really embedded enough, right? Like it wasn't really built. A lot of these tools, whether it's the vulnerability management tools or threat intelligence tools or whatever, they weren't really built with that sort of asset awareness in mind. And you need to have, have it fit together in such a way that one feeds into the other and vice versa. And I think that was, that was another key thing for us, you know, where, you know, in the early days, I remember a lot of folks were like, Hey, you know, you've got this asset discovery. Why are you building out this exploration monitoring engine? Why don't you just white label some other products and just deal with it that way?" The problem is that those products are not built for this. They didn't scale. They're very IP-centric in a world where IPs are now a lot more ephemeral and a lot less meaningful, I guess, than they used to be. And, you know, they were just full of false positives, which, you know, if you're, if you're, you know, I guess, doing a vulnerability scan of a single host, right, or a single app, and there's false positives, well, that's easy to deal with. But if you're trying to do that across 1000s and 1000s of assets, then that starts to really amplify and that becomes a real problem. And that noise actually reduces your security posture because you're so focused now on having to deal with that problem rather than being able to address the true exposure. And I think, you know, I think for us, you know, the idea that there is sort of real-time mass awareness coupled with this sort of exposure monitoring and coupled with process for fixing that and identifying and fixing that. I think that's what I think of as true ASM. It is end-to-end. It's not just one of those pieces. And that's why we did it, right?

Shubs: Just on that note, though, speaking about this end-to-end integration and having this, I guess, cohesive solution rather than a fragmented solution, this is also something that we have to deal with on the engineering side. Like we've seen several people come up with their ASMs on the internet or whatever, and they're just gluing together different open source tools or whatever. But the reality is for us to actually be able to build this cohesive solution, we need to have an insane amount of coordination between all the different processes that we're running. And to be completely honest, yes, you can pipe things together and glue things together. But you're never going to have that level of awareness that you need to have if not, if everything's not really, you know, seriously communicating with each other. Like, for example, when we discover a new port, x, y, z happens in another part of our process, whatever it may be. And this is an interesting thing because as much as we talk about the philosophy and the idea of what a real ASM is, this cohesive solution that combines both the asset discovery with this exposure monitoring piece, I feel that a lot of people that attempt to make an ASM, especially these days, or even large corporations nowadays that are using open source tooling to function a big part of their ASM, it can often mean that there's not as much coordination happening between the different pieces. within the stack, which means that they're just not going to be able to, to get that level of asset awareness and exposure monitoring that we tend to focus on and achieve.

MG: Yeah, the awareness needs to be baked into the, the, the, the engineering of it, right? Like, you know, and, and otherwise you just end up with like, just output lists of output, uh, from different tools. And it's like, is that really that valuable? Right. And maybe you bring it together in some like cohesive dashboard and maybe it works. Right. But, but it's not really unlocking the full value and it's not really about, uh, it's not, in my opinion, that's not real ASM, right? Real ASM, is about flowing it right through from, you know, the underlying assets through to the exposure, through to the remediation, right? And each of those areas needs to be high signal. It needs to be continuous and scalable. It essentially needs to be real time. I mean, that's how people want to manage these things these days. you know, this idea that you just do, you know, sort of a one-off test or, or even like a quarterly scan or monthly scan, or whatever, you know, across a handful of assets that you already know about. That's just outdated. Like that's, you know, people don't want to do that anymore. They can't do that anymore. It's, it's, it's the, the environments are too rapidly changing. There's too much exposure out there and there's too much noise out there. And so they need something to kind of cut through. And yeah, I mean, I think you're right. I think there is a real challenge with, I guess, different approaches to ASM. I think there's also a lot of confusion because a lot of folks will, in my view, just slap it onto anything. I remember when we first sort of came up with the term ASM, I was at RSA and I was like, this is an interesting idea to kind of encapsulate what we're doing differently. And it kind of had a good ring to it. And so I would, I'd be out there at RSA, like talking to folks and then ask, you know, what do you do? And I said, Oh yeah, we're, we're an attack surface management company. And it was blank stares. Right. Um, a couple of years later, after sort of the COVID lockdowns and we all sort of back in Vegas, um, I remember walking around the show floor there and every man and their dog was saying they do ASM. Even all the pen test companies, I remember, I'm a bit older than you, but when I started in the mid-2000s, every pen test company had a one, two-week engagement called digital footprint. It's basically like a recon engagement of your internet-facing assets and things like that. And that's been a staple of these sorts of consulting firms for a long time. Now, they're all calling that ASM. And it's kind of jarring because that's not ASM to us. And what we're seeing is this confusion is real because we're hearing a lot of customers that will evaluate 2, 3, 4, 5 products and then they'll come to us. And then they'll be like, this is what I've been looking for. This is what I've been thinking of with ASM. And so there is a real, I guess, there is a real underlying idea. So it's not to me, it's not just like the name of it. Like we could have called it anything, like anybody can call it anything. When people say that to me, what I get out of it is that there is something more fundamental here that they're searching for, right? And this is just the name. And ASM sounded like that was it for them, but the products that they were looking for at the time, it just didn't fit that because it's all over the place. It is literally really diverse, I guess, let's put it that way. but they are still seeking something fundamental. And I think that goes back to that point of, of that, you know, this is something that is, um, you know, that, that is how people should be managing their exposure now. And this is how people want to manage their exposure, uh, in a sort of a modern attack surface.

Shubs: Yeah. Um, You know, I remember early days when ASM was kicking off. And look, I will say that it's kind of a blessing that we do have this term ASM to describe what we do generally. And there is this emergence of ASM in general. But yeah, there's a lot of variance. But I do remember initially, like when the term was just getting a little bit popularized, and everyone was jumping onto it. I remember you linking me articles on TechCrunch and stuff where there'd be these random companies that are not even doing anything related to what ASM really is. And they'll be calling themselves as an ASM just so that they can garner attention or potentially get investment or whatever it may be, because it was the hot topic of the time. And now you've basically got every company basically saying they've got an ASM of some sort. And there's so much variability, like we've gone through and looked at a lot of these solutions together. And honestly, sometimes it's surprising what some companies get away with when they say it's an ASM, and it's just not anything close to an ASM. So yeah, in many ways, it's a blessing that there is this official segment and section of our industry for attack surface management. But yeah, you're right. It goes all the way back to pentesting days. I also remember doing similar things where we'd do these scoping assessments or whatever it may be to find all these assets on the internet. But it's nothing compared to what we really consider what ASM is.

MG: Yeah. And one of the kind of interesting elements of that is, is it's kind of, um, ASM itself has now like in a weird way, kind of, in my perspective, at least kind of fragmented, right? You have what we do, uh, which is, which is really approaching it in the sense of this is a, uh, a practice for managing exposure in your attack surface. And these are the principles and these are the workflows and these are the ways that you should approach it. That's what I would call real ASM and like true ASM. But then there's the dashboard companies, which is what Gartner calls chasm, which is just basically a bunch of integrations from different asset sources, different vulnerability sources, and things like that pushed into a dashboard that correlates them all together. but they don't typically do any kind of discovery or exposure monitoring or any kind of generation of that information. So, I mean, they're a viable alternative and they do have some advantages, I guess, but they are limited in so many different ways. And in my opinion, it is distinct from true ASM that is actually doing, you know, creating this actual understanding of your attack surface and its exposure. Then you have, I think, the service companies, right? You know, the ones that can't handle doing scanning in a scalable way that has enough signal without manual intervention. And, you know, it's kind of interesting because I hear a lot of folks say that's the only way to get high signal results. And automation, you know, is only good for limited kind of knowledge. And if you really want that, so signal that next layer of, of understanding the true exposure and exploitability, you need to need to have manual people like reviewing everything, which is absolutely wild to me, because it's like, no, no, you don't, you just actually need to know what you're doing. I think that the folks that struggle with that actually don't don't really have the ability to take the offensive security kind of mindset and sort of build that out and marry that with the engineering mindset that you need to pull that off. And I think that's why they say that rather than any kind of more real fundamental reason. I think it's just an excuse for them. And then, you know, I think you've got the pure play asset discovery players, like the ones that are doing asset discovery, but like they're not doing anything else, not in any meaningful sense. But what you've seen is all those pure play guys have been acquired by larger companies that have different tools. that they're trying to integrate in to create more of that end-to-end, to create more of that true ASM kind of experience. So everything's kind of converging there, which is good because that's somewhat of a validation, but the kind of confusing thing is, is because there's now these different angles, there's no cohesive understanding of what ASM is. And I guess an interesting trend is Gartner, right? Gartner being Gartner, they get to be years late to something and then try and define it themselves. It's like that meme where it's like, you know, I invented this thing and then they take and it's like, we invented this. And so, so, so they've got CTEM now, right? Continuous Threat Exposure Monitoring. which, again, what are they pushing? It's like, well, they're pushing that this is not a tool, it's a practice, right? It's end-to-end, right? It starts with discovery and mapping, and then it has exposure discovery, exposure monitoring, it has a remediation component, and it has to be done continuously. All of the things that we think of as true ASM, right? So now you've got this other term that's now being pushed by an analyst organization that in our opinion is ASM, but they're trying to sort of say that this is larger because their perspective of ASM is just asset discovery and asset discovery only. It doesn't do any of that sort of stuff. So it's kind of like that's also now adding a layer of confusion into the market, which You know, I guess it is what it is, but you know, and like, I don't know if it'll fix things. On one hand, it's good because, you know, it's really aligned with what we've always thought of and always done as ASM, right? It's essentially that, right? But are we just going to end up with the same situation where because Gartner is saying it, like there's now going to be a thousand people that just start calling themselves CTEM, even though Gartner is like saying this is not a tool, it's like it's a practice, right? Are you just going to get a thousand vendors that throw that out and then they're all different? Are the ASM vendors that just do discovery, that don't do true ASM, at least as we look at it, are they just going to rebrand and say, yeah, we do CTAM now?

Shubs: I've already started seeing it on LinkedIn. I've seen a ton of companies that do similar related work and every time a new term is thrown out by an anonymous organization, there's suddenly that new term. And it's a huge, they do huge pushes on this. Like I've seen companies really get into this kind of motion of calling themselves whatever they want to. But at the end of the day, it doesn't really matter, in my opinion, because I think that our customers and, you know, anyone that we demo to usually figures out really quickly what the difference is.

MG: Yeah, I mean, it becomes really obvious in those calls, right? And, and, you know, they say this is like, I was like, they say things like, I was about to give up on this project, or, you know, like, this is, you know, it's almost like they have this, like, you know, revelations, like, Oh, this is ASM. Yeah, this is what I wanted. Right. And it is really interesting to watch, which in the early days, we didn't have that, right? Because it was just sort of us. And like, there were a couple of couple of other players. But, you know, it was less about that, right? Because ASM wasn't a thing, they were just more like, hey, what's this new thing that that you're talking about here? Whereas now, because ASM is a thing, and there's so much variability in the market, You're getting that kind of reaction where it's like, this is garbage, right? The market is just all over the place. The products are just so wildly variable in terms of quality and capability, and not at all what they think of, at least instinctively as ASM, even if they weren't able to quite articulate it in the first place. And so that's been really kind of interesting to see, but I mean, we can sort of bitch and moan, I guess, about that, but like, that's just the way things are, I suppose. It's the way the security industry goes.

Shubs: Going back to your point on automation, though, I find that, you know, for sure there's a skill issue when it comes to some organizations not being able to really operationalize their research or operationalize other people's research and automate it in an effective way. But I also think that there's this huge element where there's this risk issue that a lot of organizations don't feel like they can automate things safely, which, you know, obviously you and I have had to deal with that over the last six years. And we've had to work through, you know, how are we going to do this in a scalable yet safe way across our customers? That's actually a really key consideration for us. But I find that, you know, there's this really good sweet spot that we tend to hit when it comes to finding these vulnerabilities in a very automated way, proving the exploitability without causing disruption. And obviously, we have our reservations. Of course, we're not going to send a DOS exploit to your website. We're not going to pull down any services or any things like that. But we're still going to put the effort in to find these vulnerabilities and prove the exploitability of them.

MG: Yeah, I think it comes back to people not knowing the offensive security side enough, or not understanding it deep enough. I think, you know, there might be a safety element, but I'm not sure that it's 100% the reason. I think in a lot of cases, and it's an excuse, is they don't know how to do it. They don't understand the vulnerabilities, and they're taking very simplistic approaches. right? They want to do, they, they, they do like patch level checks, uh, against the CVE database. And it's like, that's, that's it. Right. But, but then what happens is once they, once they take that approach, they realize that a, there's so many false positives with that approach, but also a lot of false negatives, right? Because it puts a hard dependency on technology detection, which is not always going to be foolproof. Right. Um, and so, So, you know, then they're like, well, how do we get around those? Right? And that's where where the manual side comes into it. And so they what they end up doing is they end up building really nuded automation, like really, really, at least from our perspective, basic automation. And then they need the manual layer to kind of supplement that to get it somewhere. And they will say it's big, that's necessary, like, that's the only way. But the more, the more I see that, the more I hear that, the more it feels like a bit of an excuse, right? Um, where, where it's, it's really a way to cover up for their lack of ability to automate this kind of level of testing at scale. Um, and I think, but I do think for you to automate this level of testing at scale, you really need to understand how it works, right? Like as in, as in how to find bugs, uh, understand all of the vulnerabilities, and understand how you how you would go about, you know, finding that and understanding that in the first place. Because you can't rely on, here's a patch level, and here's a CV from some database, right? It's not good enough. It's just not good enough. It's too, it's too simplistic. And that's what everybody defaults to because they don't, either they don't care, or they they think it's the only way to to do vulnerability management. It's like, that's why you see like, on LinkedIn, people freak out because, you know, somebody, you know, posts out there that, you know, there's 100,000, you know, vulnerabilities out there with no CVS, and everybody's freaking out. It's like, you got to tell us what it is. I don't believe you. Like, yeah, this is preposterous. I'm like, if you have ever either a reported a vulnerability to a vendor, or be done any kind of hacking whatsoever, you know, that relying on the CVE database as your single sort of driving force for finding exposure and attack surface is just limited in a huge way. And that kind of just annoys me, you know, because you have those guys that claim to be vulnerability experts, because, you know, they do nice visualizations of like, the CVE database. It's like, who cares, right? It's got nothing to do with real hacking. It's got nothing to do ultimately, with real exposure. And, you know, I think that's where people get to. And it's like, we, we've always come at it from a different perspective, right? We've never thought about it from that basic perspective. It is always like, we want to find exploitable vulnerabilities. Why do we want to find exploitable vulnerabilities and prove it's exploitable? Because then it's real, right? It's not a false positive, right? It's not, oh, you know, there's some configuration prerequisite. So this is not real. It's like, no, we've just exploited it. So we know that it's real. And then it doesn't necessarily always mean that it's going to be critical, but it might be, but it's actionable. And again, going back to those core principles of ASM, it's about what is actionable. It's about the doing, not just the discovery. It's about the doing. And so if you've got a tool or tools that are spitting out thousands of thousands of alerts, vulnerability alerts based on, hey, you're running version X of something, which might be vulnerable to these 25 CVEs, right? And you don't know what they are, really, right? There's often not a lot of information there. It's very high level. It's very vague. You don't know if there's prerequisites. You don't know if there's a mitigation that doesn't increment a patch level. You don't know all of that kind of stuff. And so what does the security team have to do? Well, then they have to kind of figure that out themselves. So then they resort to really simplistic and, and, you know, ineffective ways of dealing with that, where they'll just say, oh, well, we'll use some basic heuristics, right? We'll use, oh, anything with CVSS score, like X and above, we'll, we'll focus on remediating. But there was some interesting research that actually came out that showed that that is not essentially not that effective. In fact, it would be just as effective if they just randomly picked vulnerabilities to fix. And so so you know, you've got that problem, right. And then they also look at like, you know, terrible band-aid solutions like EPSS, which all these vendors are pushing, but really it was the vendors that create the problem in the first place, right? And so, you know, why don't you just test the exploitability? It's like, they don't know how, right? But it does, that threshold of exploitability does create a real direct nexus to actionability and signal. And so, I mean, that's why we take it, but it's not easy, right? Like it's easy to say, but it's not easy to do, right? Because it's not easy to do just in a one-off, right? It means you really need to understand the vulnerability, right? You can't just take a CVE and be like, yeah, okay, well, that's that, right? You have to understand what is the CVE. what is it doing? How can I prove on an asset that is vulnerable to this, that it is exploitable and vulnerable in a way that is high signal, right? You know, you really need to dive in and understand the vulnerabilities, which means you need deep offensive security research skills, essentially, right. And those are just generally rare, I think, you know, particularly in the web space, and particularly, particularly ones that are able to think about in the context of doing it for a product, with all those other considerations, like you said, safety and all that, right. And so, so I think that's the difference at the end of the day, you know.

Shubs: Yeah, I agree with you and taking this whole concept of, you know, finding these issues, automating them and, you know, reacting to CVEs and how organizations deal with CVEs. And I know this is a really cliche term, but, you know, often we hear like you can't protect from threats that you don't know about, for example. And one of the things that I think we really unlocked with Asset Note and the work that we've been doing was this whole concept of discovering issues, exposures on your attack surface that don't really have a CV associated There's no real thing as a CVE associate. Sometimes they're techniques, sometimes they're zero days, sometimes they're just misconfigurations. Honestly, I think that there's this huge gap when a lot of these organizations think about protecting their organization from exposure. If they focus too heavily on the CVE aspect and nerd out about EPSS scores and look at Caesar's most, you know, the most exploited list and whatever, I mean, these are all good things to do. But you know, a lot of the time it's as simple as like, oh, you had like a Git repo exposed, which had all of the credentials hard-coded in there, or you had an environment variable file there, or you had, you know, you're vulnerable to this technique of somebody taking over.

MG: Or it was the company that got popped in a big way with ransomware that was just through the classic kind of metadata IP on AWS, right? As, you know, SSRF.

Shubs: Yeah, I mean, that would have been through SSRF, but that would have, yeah. I mean, in many cases, a lot of organizations really, if they're focusing just on this whole CV aspect, there's this huge blind spot they have. And, you know, that kind of segues into something that I'm, I'm really proud about.

MG: Well, I mean, how many, how many applications, sorry, that, that people develop themselves, right? So obviously there's, there's frameworks and there's tools and whatever, but like many organizations are developing their own apps. How many of those are CNAs and assigning CVEs to the vulnerabilities that they find in those apps? Zero, right? Like, unless you're a vendor, right? You know, and so it's ridiculous. Like there is, of course, so much vulnerability, so much exposure out there that's beyond just the CVE.

Shubs: Yeah, yeah. And, you know, I think that we did make some choices quite early on around, you know, working on our own security research and building our own set of detections for everything out there. And I think these are really smart choices because it let us incorporate a lot of really interesting techniques and ways of doing things that I don't think other people do into basically our DNA and our tool sets and everything that flows through the platform. But I think what I was mentioning earlier, what I think I'm really proud of in the last six years, what we've done is we've pioneered a new way that security research can really feed into the product, as well as pioneered a new way of doing probably, I would say, the cleanest way of security research and actually, you know, seeing benefit from the product side, as well as from, you know, just generally the business side as well. You know, like we're used to, like, I know this is a bit of a tangent, but like for the longest of times, there's not actually been that many security research firms that focus on web applications. And that's changed. With ASM, we've fundamentally changed. What we've done with this model is we fundamentally changed what research companies are looking for when they're thinking about security research. And, you know, we're seeing these older security research companies get more into web applications, but we really kicked it off.

MG: Yeah, I mean, in terms of operationalizing that research, I think there's definitely that element. And it is a lot broader than just what I guess the traditional security research kind of firms, you know, would do. You know, Mark Dowd actually linked on Twitter recently, and I'll talk that he did a blue hat, which gives like a lot of insight into that market, which is insane. You know, you should you should check it out. But But yeah, I agree with you, right? Like the idea that you can take broader security research and provide that kind of value and consumability of that research, I think has been an interesting sort of side element. I mean, it's a big discussion. I mean, we could talk for hours.

Shubs: For sure. But you know, going back to TrueASM, right? And going back to this whole idea of CVs that we're talking about earlier, My point that I wanted to make with all the security research stuff, and I'm sure we'll have a chance to talk about that in more detail in the future, but the point I wanted to make there is we're not just finding things that are already out there or published as CVs or whatever. We're going that extra mile and finding things on your attack surface that You know, realistically, you may not even know it was there. It might be vendor software, it might be whatever, but it's most likely one of your biggest risks in your organization. There is no CVE associated. There's nothing there yet. There's definitely vulnerabilities, but there's no CVEs. Well, that doesn't mean you're secure. really, that doesn't mean that you're, you're fine. And, and, you know, we saw this last year, like last year, I remember, like, I think it was Klopp ransom, ransomware group. And, and I mean, it's a very interesting model with these ransomware groups now where you've got, you know, basically, basically mercenaries who have zero days who are going to these ransomware groups and using them as a service. Someone really made bank off the move it vulnerabilities that they found. And that's now a whole new monetization vector for security research. If I'm a security researcher, and I find a zero day in a really popular enterprise software, I don't I don't need to report it to the vendor.

MG: There doesn't need to be a CD on the legal side. There's bounties as well, right?

Shubs: Like there's, of course, there's bounties and all that. There's many different ways. But I'm talking about like, especially for our customers and other people that are looking to get an ASM that actually does this level of research like us. Um, we're trying to prevent against, you know, these, these malicious parties that are, there's no CV associated, but they're going to get compromised through the zero day in some random file transfer software.

MG: Yeah, yeah. And I mean, this is a bigger topic that we talk about a lot. But a lot of folks don't really understand the level of exposure that's being introduced into their attack surface because of this. And I think if you think about ASM and you think about it in the way that we look at it, what true ASM is, which is looking at identifying the real exposure that's in your attack surface um you know on a continuous basis with a view to to addressing that right um if we think about that um you know there is you have to look at this stuff right otherwise you're not looking at the true exposure you're not identifying the true exposure you're just going to miss a whole bunch of stuff and i think it's really important um and it's been really great too because it's not easy it's not easy i mean our team i'm constantly impressed how quickly our team finds like crazy bugs in really complex code, really complex, widely deployed enterprise software. But yeah, I mean, it's a real problem, I think. And you're constantly, you know, our customers are constantly coming up to us being like, this is amazing, I, you know, I, you know, I, I am really concerned about this, because this is everywhere, or this is this nature of this software, or whatever. And we have absolutely zero visibility into it, because the vendors not giving us anything, the vendors were very opaque on the security. And, and our team doesn't have the capability to do this level of research, or even the capacity to do that across across all their, you know, their entire attack surface. And so it really unlocks something else, I think. And yeah, I mean, there's multiple angles to it. But, but yeah, it's been interesting to sort of see that grow as a real vector for, for broader security research. Because, you know, if you think about it, right, that kind of mirrors the the broader sort of vulnerability market, I think, right. So, so, you know, if you look at like the, you spoke about the traditional the traditional sort of security research shops, you know, they're focused on, often these days, it's mobile, right? Because of who they're selling to and what that means, right? And so there's that side of it. Then, you know, sort of even, you know, taking it out of that sort of law enforcement government side, right? You know, the traditional attacks were always against credit card processing, right? Because that was the easy way to monetize those vulnerabilities. Nowadays, you know, with ransomware, right? It's a much broader way that criminal elements can monetize these security vulnerabilities for them, right? It doesn't have to be a credit card number. It can be a vulnerability in a VPN that allows them to just lock everything or extort them. Right. And so one that opens up the number of companies that they can target effectively monetize. Right. It's not just people that are doing this kind of credit card processing or something that they can easily kind of translate to cash. And, you know, it's opening up the different ways in which they can do that. And so, you know, in a way, doing this kind of research in that sort of broad-based, you know, way and looking at all of these sorts of attack surfaces holistically is kind of a response to that in a way. And it is following that. Which I just found interesting. But yeah, I mean, it's certainly fun for us at Asinote to get to sort of, you know, look at and break a whole bunch of, you know, really critical software, basically, that all these customers use and pay millions of dollars for that's just exposing them in some amazing ways. Obviously, we can't talk about some of the detail there, but it's just, yeah, it's been mind-blowing for me, at least.

Shubs: Yeah, same. And look, like I wouldn't say that I'm expert at the traditional security research industry and how they operate. But I will say that what we've done with our security research team, and obviously many people are following suit with what we've done and looking at what we've done as inspiration, I think that's a part of true ASM. I think that's really a part of, I think it's a very core fundamental pillar that we rely on to find exposures that customers don't even know about. There's no CVE at all. And, you know, this is just feeding all back into this discussion. I think that your point about organizations focusing too much on known CVEs is actually a bit of a threat to their security posture. And they have to really question what is on their attack surface, what real exposure do they have?

MG: Yeah, yeah, it's kind of, it's kind of really simplistic thinking. I mean, the other side of it, and what makes it hard as well, is often, often when there's a CVE, there's the remediation side is quite clear. It's usually a patch, right? Whereas when it's kind of new or when it's not necessarily as straightforward as that, the remediation might be unknown or different. And from our perspective, when we're doing all this research, another key element, and this ties it back to how we view ASM, and the key element is that we're developing mitigations and remediations for these issues that aren't just the vendor patch. Because I think that's really important. It's not just identifying the exposure in the attack surface and trying to be holistic, not just with mapping out the attack surface, but understanding the holistic exposure across the entire attack surface. It's about being able to do that in real time so people can be reactive to that level. It's about what they do with that. It's about, you know, the whole point of being high signal is so that they fix what's real and they're not spinning their wheels. That's the doing part, you know. And so when it comes to research, it's not just about, you know, an understanding, you know, how to find these vulnerabilities. It's not just the research. It's also understanding enough that we can say, hey, look, you've got this exposure. But this is what you can do, you know, to mitigate your risk, and to deal with your risk. And that's, that's sort of the key driver at the end of the day, that that flows through everything.

Shubs: And I think that that really goes to what, you know, sometimes it takes our teams weeks to come up with those mitigations. Yeah, like if I think a lot of people may not realize this, they might just read our blog posts and think, oh, well, that was some cool research or whatever. But behind the scenes, we're actually working really hard to actually secure our customers and not just scare them with vulnerabilities or whatever. It's like, no, we have a solution for you long before the vendor has a solution. And I think that a lot of people don't realize that the amount of engineering work and security research work that goes into the actual remediation sometimes is as lengthy as sometimes it takes to find the vulnerabilities. So it's crazy.

MG: And it's really important because a lot of folks that You know, I think there's a lot of folks that will look at the research and utilize it either as a tool just simply for marketing, right? You know, often those bugs aren't really that interesting or that great or that impactful, but like, you know, they'll use it and they'll put it out with all the kind of hacker tropes. right? Like, that are just boring and dated, like, let's be honest, right? And then there's sort of others that, you know, don't think of that other side, they're just like, we're a hacker, we're, you know, we're going to do this, right? And we're just going to lay it out there. But like, when you think about it, what's the point? you know, from from from what we do from an ASM perspective, right? It's like, if we didn't do that, right, what we'd be doing is showing them a bunch of exposure and all these tools that they're using, and and saying, Well, you got to sit tight and wait for a vendor to fix it. Right? Like, have a good day, you know. And at the end of the day, like, what's the point?

Shubs: Actually, people freak out at that. because they've now got risk on their attack surface that they can't do anything about.

MG: Yeah. Yeah. I mean, it's definitely interesting. And so, you know, again, like you said, the core focus for us is not about, even though we're finding interesting vulnerabilities, we're doing really deep technical security research. even though we have this platform that's able to scale that out to an insane sort of scale and speed, you know, despite all of that, you know, the underlying principle is fixing the exposure, not just the, it's the doing something going right back to, to sort of the early days where it was just like, you know, most people were focusing on asset discovery. It's like, that's not the end in and of itself. right? It's what you want to do with this. And it's the doing part that really matters. And so, that's why we go to that. But it takes a special kind, right? It takes somebody that can understand the actual vulnerability enough to exploit it, who can understand that in a way that it can be applied to a platform that does this at scale. right, that has other constraints like safety as well, who can then understand enough around, well, how do I fix this issue, right? Often in a very black box way as well. And, you know, I think it takes a sort of special kind, right? It's not trivial. It's not an easy thing to do. And that's why I think other sort of products and tools end up with that more lazy approach, right? it's because it is hard, right? And they take the more straightforward option at the end of the day. But yeah, I mean, there's heaps of stuff to discuss on that topic and all those elements. But yeah, I mean, I think you know, we could probably sort of wrap it up there. We've got to save some content, I suppose, and some discussion for later. But I think that's a pretty good overview. It'd be interesting to see how this market continues to evolve. It's an interesting space to be in. you know, at the end of the day, we're more focused on the core problem, right, that we're trying to solve and the product and all of that stuff is interesting to observe. But at the end of the day, it, you know, it just comes down to are we helping our customers, right? Are we making their lives easier, better, more effective? And are we actually helping them manage exposure in their in their attack surface. That's all that sort of matters. And that's the focus. But sometimes it is interesting to discuss all of this kind of meta, you know, market.

Shubs: And I guess to end it on, you know, just some reflection, I think on my side, one of the things that I really appreciate with what we've done with our our idea of the true ASM is just seeing that effort that we put in really lead to the results that we're looking for. Just this last weekend, we spent a long time reverse engineering a vulnerability that there's no public POC for, and you know, we can operationalize that within minutes once we have the POC. And it was just really amazing to see that, you know, after the amount of effort we've put into engineering, product, business, everything, and with our customer base, and seeing all of our customers get that immediate value from the work that we put in. And it's not just security research, like everything is dependent on each other. Like we wouldn't even have security research as a pillar if we didn't have a reliable, solid product to be able to operationalize that research. So all of the engineering feeds in, we wouldn't even have the ability to, you know, have such a great impact if we didn't have the business and the amazing customers that we do to be able to, to find these issues for, for them. Um, so, you know, everything kind of feeds into each other, but yeah, that's, I really see true ASM. If you get it right, then you, you might be in a similar position where you can actually get this level of opera operationalization for, for operational, operationalizing security research, where we just find these issues. across our customer base very, very quickly once we've got the POC?

MG: Yeah, 100%. I think everything's converging there one way or another, right? You know, I think the pure play sort of discovery sort of side is going by the wayside mostly through acquisition. And, you know, the ones that don't get acquired are either going to have to move towards true ASM or not, right? Or go bust potentially, right? Um, you know, I think, I think that's where everybody's converging, uh, on, but it's also people are coming at it from a different way. Like the startups are coming at it like us, which is sort of building it up. You know, the, the bigger companies are coming at it from, from acquiring, uh, and then trying to integrate. Um, so it'd be interesting to see, but I think, you know, in a way that kind of validates that that's what people are looking for. Right. And I think, um, I think that's, that's really what it is for me is, is that it is a fundamental shift in how you approach, you know, managing your security exposure in a modern attack surface. And that's what people are looking for. And, and, you know, that's, that's why it, you know, has resonated, you know, and, and why this approach has helped people is because it's, it's based in something more fundamentally real. And, and, and concerning for customers. So, yeah, no, I think that was good. I think we can wrap it up, but plenty more to discuss in the future. I think there's definitely some interesting stuff there. You know, talking about security vulnerabilities, security research, you know, shadow IT, I think is an interesting area. Talking about how terrible an idea EPSS is, or a half-baked idea that EPSS is, I think that'll be an interesting one too. but I think we can probably wrap it up there.

Shubs: Let's wrap it there. All right.

‍