Confusion in the Attack Surface Management Market - Surfacing Security Ep 6

MG:
I guess what I wanted to talk about this week is you diving into this, this idea of, of attack surface management and ASM, because, you know, it's been interesting, you know, we've been doing this for a long time now, we're like six years in to the business. And we were doing this well before attack surface management was a thing, you know, we were, we were, you know, one of the first in that space. And it's been interesting to see how it's kind of evolved, you know, and how it differs from, you know, how we've thought about it. It's interesting, because for us, at least, you know, ASM has been about I guess sort of the core principles that we started with, you know, coming from the bug bounty space a little bit, right? It needs to be, you know, holistic, continuous and focused on finding, you know, exposure, security exposures. You know, the core principle that we had was asset discovery was never the end in and of itself, right? Like we used to say that all the time. It was like, what do you want to do with that? And it feels like the market's kind of focused a little bit more purely on discovery and less on the exposure management side. And it's been kind of interesting to see how that has evolved and the kinds of different tools, I guess, and products that have spawned up in this space and how people both from you know, company perspective, but also from, from like an engineering perspective, think about ASM. You know, I remember, I'm much older than you chubs, but I remember like in the early days, you know, back when I started my career that like I was working for for pen test companies, and every pen test company would have this service called, you know, footprint or, you know, digital footprint or external footprint or something like that. And it was basically like a one two week engagement of of you know, mapping out your external attack surface and you're providing a list of assets effectively at the end of it. You know, that's been around for like, you know, 20 odd years almost. And now like every single security testing company that does that exact same service calls it attack surface management, you know, which is very different to, you know, the kind of in-depth engineering that we do to build a continuous and automated product. And so I wanted to dive into that kind of idea a little bit more in terms of how that kind of has evolved. And also, you know, thinking about, you know, what is ASM at its core? And, you know, can you utilize these sorts of off-the-shelf tools and these open source tools to be effective or not? So that's sort of where I wanted to start. Do you have any kind of thoughts from your perspective on how that sort of term, I guess, has sort of evolved since we started?

Shubs: Yeah, I do think that it's Like when I look back at it, I am a little bit, I guess, a little bit proud that I think we really made a movement in ASM when we started and we were focused really on vulnerabilities and exposures generally. I do feel that a lot of companies have kind of converged into this idea that we do need to find exposures, not just find the assets. But I agree with you. I mean, there's so much variance in the term. I mean, there's companies that are kind of like dashboard companies, there's companies that just collect assets, there's companies that focus on graphs, there's companies that are just focusing on connectors and things. So it's wild. And they all call themselves ASMs.

MG: There's companies that don't even do what I would consider ASM that call themselves ASM. I was reading a TechCrunch article not too long ago and it was like a typical like, hey, you know, PR, obviously PR sponsored kind of thing, you know, such and such company took, you know, X in a series A and it was like, attack surface management takes X series A round. And it was, I'm like, okay, like, oh, let's check this out. You know, I look into it. And the article is talking about attack surface management, how important attack surface management is. And so I'm like, okay, who's this company? So I click onto their website. And there's not a single mention of the words attack surface management. It's a container security company. It was a company that was, you know, kind of automatically you know, removing like unused dependencies and other things like that in that's installed in these sort of containers. And, and I guess from some level, you could call that like, reducing your attack surface. But to call that attack surface management is a huge leap. And, and it was quite interesting, because it had nothing to do with their product. And, and, you know, nothing to do with what, you know, as varied as it is, the rest of the market, you know, considers ASM in any way, not even like asset discovery, right? Yet, you know, this article, and these, this sort of VCs, I assume, we're really using it as this kind of buzzword term, which is kind of, kind of interesting.

Shubs: Yeah. And, you know, I think the amount of variance that we have in this field with the term ASM is actually causing kind of a disservice to the general people who are looking to get into this field or buy a product in this field, because they often don't actually know what a real ASM is or what a true ASM is until they see one. And that's, that's, you know, that's, sometimes they may not even see one, and they might just resign and say, Okay, this dashboard company or whatever is giving me all my assets, that means I've got a management of my able to manage my attack surface, but that's not really what ASM means, at least not to us. And, you know, one of the things that I often find is, you know, there's, I feel like in the last couple years, there's been like this emergence in this open source space. And generally, with people trying to claim that you don't need an ASM from a vendor, you can build it yourself with off the shelf open source tools. And I also think that's a little bit of a disservice because it really, really doesn't go towards what we believe the core pillars of ASMR and what you need to be able to actually manage your attack surface. And, you know, it's difficult because, you know, there are a lot of people in the industry that may not come from an engineering background or may not come from a offensive security background that may not understand what is really required to manage your attack surface from a workflow perspective, from an exposure discovery perspective, from an asset discovery perspective. And even just from, from the raw engineering of making that happen as well, you know, and I think, yeah, I mean, I often, I don't know about you, but I often find that people, and I don't know if this is just based on a few experiences I've had, but people often don't understand what goes on behind the scenes to build an ASM that's actually capable of doing what it says and what it's supposed to do.

MG: We get that a lot. I mean, like in the very early days, you know, we got, you know, what, why, you know, you're building out acid discovery, why are you building your own exposure monitoring engine? Right? You know, why don't you just white label some scanner? And it's like, it doesn't work for what we need it to do. And like, we have a very, you know, specific vision of, of basically real time monitoring of your external attack surface. And that's a huge, as you said, behind the scenes engineering effort to meet that standard. And we're very focused on that standard. And we do that only because there's so much value that comes from it. But I agree with your point that The market is, you know, this is the sort of the rhetoric out there in the market has led to a lot of confusion for buyers, right? You know, not just from the commercial sense, right? But also in the even in this concept, like you're sort of saying, of the build versus buy element, right? I don't think they really understand. you know, what it what it is, or they don't have a good picture of what it is to to sort of build and maintain this, to get, you know, a standard. And, you know, it's kind of interesting, you know, where we hear it, you know, very often with our, the people that we speak to the companies that we speak to, where they'll say, like, we've we've looked at 456 vendors and in the market, and you know, then they heard about us. And they they sort of said, you know, we're ready, we were ready to give up on this project. you know, the the state of the market is terrible. And, and then they sort of see us and they they have comments like, Oh, this is what I was thinking of, when I thought of ASM, this is what I was kind of looking for. And so this is the element where, where ASM is kind of really loosely defined. by various marketing groups, as well as analyst firms, I guess, and it's creating this confusion, but like, there is still a sense of, you know, what they were hoping to get, I think, you know, there is there is something more fundamental to it, right? It's like, what they're, what they're looking for is that kind of complete visibility into You know the attack surface not just what the attack surface is but what are the exposures and the problems inside the attack surface and what do they need to do about it. And so you know once you have that kind of understanding it kind of you know obviously there's. you know, they can evaluate different vendors and, you know, look at the pros and cons and do POCs. But I think an interesting kind of element of that is, is how, how it influences the kind of build versus buying kind of decision making that's, that's typical of a lot of, at a lot of companies, right? Particularly those that maybe have a stronger engineering culture. And, you know, they'll look at, like you said, there's a bunch of open source tools, you know, doing various components of what you might consider ASM. And they think, oh, well, that's easy. I'll just run these guys. I'll just run these tools. I'll just string them together. But it doesn't really work effectively, right?

Shubs: Yeah, and the reason it doesn't work is because if you want to hit any of the same levels of continuous scanning, or the scale that you may need to hit in most cases, as well as quality and output and workflows, that stuff doesn't exist. So I mean, unless you go with an actual vendor, I feel like these days, you're not going to be able to get those additional benefits. And even then, some of these vendors at the end of the day are just gluing things together anyway. It's like, you know, how many vendors do we speak to? And they're like, Oh, we just glued this tool in this tool. And that's how we get this. And it's like, yeah, yeah, you're not gonna actually get the quality from that. So there, there is definitely an element of that. But, you know, I think I think that one of the things that people can, you know, really often do when it comes to ASM, which is what I've seen is grossly underestimate the difficulty of reliable scanning and quality output. Cause that's, that's the two things that I think, uh, reliably reliable scanning and discovery and quality output. I think these, these things are probably the most difficult things when it comes to building an ASM. Um, but yeah, I don't know.

MG: I see this all the time. Right. Like, so let's dive into like the scale side of it, you know, um, thinking of, of scale, both from a discovery perspective and exposure scanning perspective and, you know, what it takes to engineer that, um, You know, I think what's kind of interesting as well is, you know, there's so many different people that, you know, get into this space and sort of, you know, like you said, glue tools together and think, Hey, like, I've got a product that I can sell. But you know, there's, there's often not a lot of core value there. When you think about our, our history, right? You know, the a lot of the ideas, around this came well before Asinote was even formed six years ago. And it came from actually doing this, right? Actually, you know, looking at large attack surfaces and trying to find exposures, you know, from a bug bounty perspective, right? And so there's a lot of like, there's a lot of, you know, putting engineering aside, there's even just a lot of like, really nuanced elements to that, that you only really get from experience that we've had from the beginning that, you know, you sometimes see people, you know, talking about that. And it's just like, you know, you know, three years into them starting a company, and they still haven't solved that problem that, you know, we had sort of solved from day dot, because we knew it was a problem from day dot. And that's kind of interesting. But, but on, you know, on the engineering side, you know, talk me through, you know, how you think about the scale, and the challenges with with the scalability, because you're right, I hear it as well, where, oh, well, I guess it's, it's easy to build this, You just take this tool, and then you just pipe it to this tool, and then you just put some pretty interface on it, and there you go. Bob's your uncle, you've got an ASM. But it's really not as simple if you're trying to get effective value for the end user. Talk me through some of the scale challenges.

Shubs: Yeah. Um, and, and I guess one of the things I will, will quickly clarify is look like if you're just some random bug bounty hunter, um, probably using some of these off the shelf tools is not a bad start. But if you're a, if you're an enterprise that's looking to actually build an ASM, that's going to hit some of the things you need to do internally and actually is reliable. Then you really need to think about this a bit more. And I guess when it comes to engineering, one of the things that's probably most important is the accuracy of the results. And what we find and what we found over the last six years is getting to that level of accuracy on a very continuous basis comes with a lot of challenges that aren't necessarily related directly to the code that you've written or you're running. Sometimes it's often to do with the networking layer. Sometimes it requires you to really reconsider how you architect something or how you do a certain process. And, you know, the accuracy side of things is not a trivial problem to solve. Um, actually like even in just terms of scale, right. Um, the, the, the faster you're going and the bigger the scale, the more likely that your accuracy is just not going to be as good as what it is at a small scale. And that's due to various reasons, obviously due to things like timeouts, due to things like networking issues, whatever it may be. But I think that, you know, when a company says to me they're going to be building and they're not going to be buying, I feel that like they may not consider how much time it's going to take to actually build something that's reliable and performs in the same way as someone that's like vendor like us that's been doing this for six years, that has kind of pretty much ran into all of these issues along the way. And we've had to solve them like we can't like, we've had to solve these issues. And they've been incredibly difficult to solve in many cases, but we've solved them. And this is where I find this whole argument of, you know, internally, we're just going to glue some of these tools together, we're going to pipe it to some Jira tickets or whatever, and we're done. I don't actually think that they're recognizing what is happening under under the hood, when it comes to what they're missing out on in terms of reliability and quality, as well as, you know, sometimes I feel like they can trivialize the problem. Yeah.

MG: Yeah, a hundred percent. And, and, you know, I think it comes, I mean, there's two elements to it, right? It's if you don't really care about the value and the output at the end of the day, well, what does it matter? Right. And, and, you know, I think, you know, to your point earlier, if you're a bug bounty hunter, you have a different output, right? You have a different, you have a different perspective. But, you know, one of the big things that, that, you know, we've focused on has always been about, okay, there's value in that approach, right? There's a value in large-scale discovery and scanning and doing that, you know, quickly. But how do you make that consumable to the end user, right? To the customers who have to fix this, you know, and I think that's a real part. It's kind of the management part, right, of attack surface management. And it's a part that's sort of forgotten, but it does, you know, come from the basis of having you know, accurate and timely results. And, you know, I think there's some some interesting, you know, points to that, right? If you look at it across the board, you know, whether it's the asset discovery or enrichment sort of side of it, or whether it's the exposure scanning side, you know, there's a lot of challenges there, right? So like, for example, a lot of tools will just spit out any kind of assets, you know, say subdomain assets that they get from whatever sources that they're checking, right? Um, that doesn't necessarily mean that that's real. Like there's lots of, there's lots of challenges there, whether it's like, uh, wildcard, you know, DNS wildcards, whether it's, you know, um, you know, assets that don't resolve, like if it doesn't, if a subdomain doesn't resolve, right. How relevant is it? Like, is that really an asset at this stage? Right. Um, And how relevant is that from an exposure monitoring perspective? And so I think there's that side of it. There's also really nuanced stuff. So if you're looking at doing something like port scanning, as an example, and you're a company, and you're using a cloud provider, if you're trying to do anything at any kind of scale, you run into heaps of problems. So you run into probably the biggest one is accuracy if you're going if you're going too hard, you know, we've experienced that on AWS and you can talk to that. But even just things like abuse requests, right? You know, around things as simple as port scanning.

Shubs: And you know, I think that some distinguished engineers might look at the bug bounty space as a bit of inspiration and see all these bug bounty hunters who are automating some of this stuff and say, hey, I can do this too. And this isn't that hard. Right. Yeah. But let me tell you, there's a huge difference between what these bug bounty hunters are doing for automation versus what you need as an ASM. Right. Like for example, I have a very good friend of mine who's probably one of the best bug bounty hunters ranked on top three on almost every platform. And I know for a fact that some of his methodologies, they work really well for bug bounties. But when it comes to something like an ASM that you need to use for your internal organization, they're not really ideal. Like, for example, just one example, I think one of the things I heard of some time ago was, you know, the way he deals with DNS wildcards, which obviously at Asinote, we have a very specific way of dealing with that, which we've refined over the last six years. But his way is, oh, if I see more than 50 or a hundred records under a single subdomain, I just discard all of them. Cause who cares? And we'll just keep going. We'll keep chugging along kind of thing, which, you know, in a bug bounty perspective, he's just making quick decisions to get to the outcomes he wants from a bug bounty perspective. That doesn't necessarily mean that that's the best way to do it. It means that it's the fastest way to just kind of deal with that problem without too much annoyance, I guess. And, you know, I guess the other thing is, um, in the bug bounty space, uh, and generally with ASM. We do have a lot of open source tools on the market now. We do have a lot of, I guess, signatures or templates that are written by the community. I don't really think that these templates and signatures have that much quality control, just based on my experience. And yes, there is definitely some quality control, like there's a PR process and a review process and so on. But it really doesn't feel the same as how we do it, to be honest, and how much rigor we put into it. So some of the things I'll often see is… requests that don't need to happen or are irrelevant entirely, testing software that's never going to exist on the internet, or sometimes worse, when it's testing it in a way that's disruptive, sometimes testing it in a way that doesn't actually lead to the results that you're looking for, sometimes relying on out of band infrastructure that you're not in control of in any way or form, and it's just some third party you got to trust. Which I understand. I mean, it's, it's the same as those vendors, but it's not the same in the sense that it's some open source tool.

MG: That's just some, some random service.

Shubs: You've got no contract with them. You got no nothing. It's just, yeah. You're going to just use their out of bounds. Yeah. Yeah. Yeah. But, but anyways, um, there's definitely, um, there's definitely a huge variance between what bug bounty hunters are building for their tooling versus what you probably need as an enterprise.

MG: Yeah, and then the other side of it as well is just, you know, forgetting some of these, you know, putting aside some of these elements, right? Like, you know, the accuracy, you know, the speed and scale. Where do you want to spend your time, right? Like, do you want to be there dealing with these challenges, right? And, you know, maintaining this sort of infrastructure? And, or do you want, you know, as a security engineering team, or as a security team to be focused on, you know, the actual output of that? And, you know, what do you want to build? Do you want to build, you know, custom things on top of the platform that's handling all the scaling, the infrastructure management, you know, dealing with AWS's you know, extreme, you know, networking stack restrictions, you know, all that kind of stuff. And then you can just build your sort of logic and your custom stuff on top of it. You know, or do you want to really, you know, be maintaining this kind of, you know, infrastructure on a day to day basis, like what's, what's sort of worth your time. And, you know, I think, you know, what we've seen is that there's a lot of people that have tried that, that, you know, come to that realization eventually, you know, usually like a year or two in.

Shubs: Yeah. And let's not even talk about all the integrations you need to build. I mean, think about it. If you're going to build an ASM, it's not just there to exist in a vacuum. You've got to have all sorts of attribution information coming from some source in some way or form, like AWS or at Azure or whatever it may be, you got to have all the cloud integrations. And one of the things I find really interesting is there's a lot of, I guess, I feel like there's a lot of companies and a lot of times in the build with spy case, people underestimate the scale that they're going to need to go at. I think a lot of our customers that have any of these cloud integrations, they sometimes have thousands of accounts. Um, and I know how much work we've put in to actually get that process to be so optimized and at speed and scale that it can support unlimited number of accounts. And look, a lot of this stuff sometimes goes all the way back to the architecture and infrastructure choices you choose from the beginning, because you may not even be able to scale it to this speed and scale you need, if you haven't made those decisions right at the very beginning. So, you know, there's a lot of gotchas with this. And it's not just like you can glue things together.

MG: Yeah, and depending on your tax office, right, if you want to monitor this continuously, which everybody does, because that's the right way to approach it, right, is your idea of continuous like once a month, right, or once a week, even, you know, it's like, maybe, maybe that's good enough, like for for your particular organization. But for most people, you want it to be faster than that, right. And if you've got any kind of scale, Um, not only to your point, are they, you know, are they inefficient? They're sending requests that don't need to be sent. Um, they're potentially disruptive. I mean, these are things that, you know, for better or for worse, bug hunters don't care about, right. Um, you know, when they're, when they're using this sort of tooling, um, you know, against, against an attack surface. But these are things that the defenders actually do have to care about. They have to think about safety. They have to think about, you know, the load and they have, you know, against those, those assets, they have to think about, you know, things like, you know, how effective is their sort of time in terms of having to look through and manage the results? How can it how can you know, they consume it to remediate these issues. And, and so you know, you have to you have to consider all those points. And they're not trivial. And you know, it goes to the consumability of this. And I think I think that's, I think the the idea of, of sort of build versus buy in terms of what I've seen, you know, in this space is just, you know, it kind of goes back to what we were talking about earlier, where, where there's so much variance in what people, you know, claim is ASM, versus I think what, you know, the majority of people want, as sort of the end consumers of this, and, and they're just sort of being somewhat disillusioned, like, you know, last year, we were working with a tech company out of California, and you know, it was one of those stories like I mentioned earlier where they were, you know, looking around for various products. And, you know, basically, you know, the gist of his sort of result, the result of that analysis was, you know, the ASM market is terrible. It's crap was the term that he used. Right. And, and he sort of put it out to social media. It's like, before I build my own, because there's literally nothing that serves my needs. Is there any, is there anybody else? Right. And, and, you know, somebody in his, in the comments, I guess, on that post mentioned us. And, you know, that's where he had this sort of epiphany. It's like, this is what I was looking for. And so they're coming at it with a very specific expectation of what they want. And this company, like I mentioned, they're a tech company. They have a strong engineering culture. They could build something, right? It's not like they're completely averse to building something. But they recognized, obviously, that there is a maintenance cost to doing so. And so they were looking at the market. But they just weren't seeing anything that made sense. And so I think, I think there is a bit of this interplay between this idea that, you know, the market is so like fragmented, and so, you know, so kind of confusing for, for, for these customers, you know, that that drives, well, maybe I should build it myself, you know, maybe we might get a better outcome. if I take some of these open source tools or take some of this stuff and kind of just hobble it together to try and tick the boxes that I'm trying to get. But then, you know, I think our experience has been that they eventually realize that that's not an effective or sustainable solution at the end of the day.

Shubs: Yeah. And, you know, I think that it can be really tempting to build something instead of buy something. I just realistically seeing some of these security teams that that we work with, and, and a lot of a lot of companies in general, I feel like they're really hard strapped for time. And they don't have, I really don't feel like managing an ASM is something that can be done kind of like as a side project or as a part time thing. It is a pretty full-on thing, even if it's just for a single company. Because as I mentioned earlier, all the same scaling problems that we deal with at AssetPort, or have dealt with already, are still going to hit every other company that tries to deal with this. And look, there are more and more, I guess, ASMs out there now. And because of that variance, you don't know if you're going to be able to find something that fits your needs. I don't know if this is inspired by us, but I am finding that there is this convergence that at least exposure scanning it's becoming kind of a more common thing in ASMs, I guess, today, which is really, really interesting, because we've been doing that for six years, right?

MG: So that's not like a new thing. That was the idea from the get go for AssetNote. And what was interesting is chatting to some of the other big players at the time, you know, their perspective was like, Oh, well, why don't you just build an integration with like, you know, a vulnerability scanner, and like, you know, just pass it over. Or, you know, isn't it enough just to tell you that you've got this technology running on your attack surface? Isn't that enough, right? Like, that was their mentality. And, you know, I was talking to the CEOs and the product leaders at these companies, right? That was their mentality. And we were like, no, that's not good enough. You know, it's not, It's not good enough from a signal perspective. It's not good enough in the sense of nobody just wants asset discovery, right? No, like people want it, like, why? What's the point, right? Just so you've got a list of assets, you know, like what they what they want to do is it is foundational is very important, but it's foundational in the sense that it enables other things, right? So if you just think about exposure scanning as a use case, right? um you know the idea of why would you want asset discovery to pipe into a vulnerability scanner via an integration well so you've got coverage of everything so you're not missing anything because what's the point of of scanning for security exposures if you're not looking at everything in the first place Um, you know, cause you're going to miss out on it. Right. So, so, you know, it's, it's for something else and it's to enable something else. And, and, you know, back in the early days, you know, that was a, that was a very radical kind of shift. Um, that, you know, I think to your point, people, you know, people have been starting to catch up to, right. Um, people have been starting to come around, you know, I think it's, it's driven by a lot of different things, right. It's driven by. you know, just just generally customers sort of seeing that in various vendors that are doing that. And again, this is what I want. So it's driven by customers, but it's also driven by a lot of acquisitions in this space. You know, if you look at a lot of the acquisitions that have happened, um, in the ASM space, it's been, it's been of those pure play discovery, you know, kind of products, right, that are just doing discovery. And then, and then they're building it into like a larger platform, you know, or other integrating with other products that already exist. for that exact same purpose, right? It's like, well, these, these use cases, these things that we want to do with their exposure scanning, your threat intelligence, whatever, you know, it's going to be made better by this, right. And so, so they're doing the same thing, like they're coming at it from the same, you know, they're looking at the same, you know, problem, but they're just solving it from different perspectives. So whereas we build it from the ground up, and, you know, a deeply integrated from the get go, you know, they're coming at it through by acquisition. So I kind of top down, right, they've already got all these other products. I think that's, kind of change their thinking, you know, you know, for better or for worse, but that's kind of gotten people, you know, on, you know, on to sort of our thinking, I guess, on, you know, attack surface management is not asset discovery, it's what you do with that. And it's sort of enabling these core processes with real time, you know, asset awareness and building that into these core processes. That's the key value point. And, and you can't do that. You can't do that. If the sort of core processes, exposure monitoring, threat intelligence, incident response, all those things that you want to do, you can't do that if they're not built with that asset awareness in mind. It's just really like a subpar experience. And so that's the approach that we've taken. And it has been interesting to see that development. But again, the quality of that is across the board, right? So when we take a concept like that, when we talk about as I discover in exposure monitoring and the various forms of exposure monitoring that can take, it's so deeply intertwined. When we think about it from an engineering perspective, a product perspective, just our philosophy, they're not just standalone things. One feeds into the other and vice versa. But what I'm also seeing, just to your point, It's not just like, you know, end users that are like, Oh, yeah, maybe I can just run this off the shelf stuff very easily. It's, it's companies, right? That, you know, you know, often they're pen test companies or, or companies of that, that sort of nature that are more services based, that are trying to, you know, build something that's, I guess, a bit more of a product. And they're doing that, right? Like they're taking like some really basic asset discovery and they're just, you know, providing scanning with these open source tools, right? Like I saw one the other day I was looking at, and then they don't even hide it. Like most people try to hide it. Like when we find out about it, it's kind of like, oh yeah, like behind the scenes it's just X tool, right? I'm like, oh, okay, that's interesting. But like, these guys were like, no, it's based on their pricing, right? So on your cheapest tea, you get open bass, and on your more expensive tea, you get nuclei. It's like, why would you pay for that? Right? I don't understand the value that you're actually getting on top of that, especially given that, you know, the output of both of those tools is not great when you start to do things like scale it up, right? Well, like, when you know, if you've got an asset, And there's a couple of false positives, right? On its own, that's not a huge issue to deal with, right? You can just sort of weed them out and ignore them. But what happens when you've got 1,000 assets or 5,000 assets, 10,000 assets, and there's a few false positives on all of them? Right. That's like thousands of results that that are just irrelevant. Right. And so what do you want to weed through all of that? Right. You know, and then, you know, it takes you to run those tools against 10,000 assets. It takes you forever. Right. you know, do you, you know, to really, is it really that that good of an experience? And, and it's just surprising that people would pay for that, right? Because there's not really much that they're, they're offering on top of that. It was just it just shocked me. Yeah. So, you know, like, on the on the vendor side, like, not just the bug hunters or the build side, right? We even see on the vendor side, which is

Shubs: You know, I still think some of my favorite feedback when it comes to what we've built is that when we raise something, they know that it's important. So they're going to, they're going to actually look at it and they're actually going to spend the time on it compared to other tools, which are raising thousands of things. And look, you're not wrong. Like, um, a lot of these tools do have thousands and thousands of things. They, they check and look for and raise and things like that. But I do think that they take this approach where they kind of ask you to filter things out in terms of, oh, only scan for these things, only filter these things out or wherever it may be. And I think one of the big things, just to go back a little bit on the spilled us by and you know, a lot of these competitors that we're seeing that are trying to glue together these open source tools and whatever it may be is, I'm actually, you know, I'm actually not sure if they've dealt with some of the issues we have yet, or if they have, they're going to have potentially some customers that do experience a lot of difficulty is all the safety side of things that we've had to build. And I know we've got some real war stories there when it comes to that sort of stuff. And we've done a lot of work in terms of building that into everything we do from the scanning perspective, from everything else. Like for example, let's just say you've got these open source tools and you've got some asset discovery or whatever it may be. It discovers a thousand new subdomains today and all of them are pointing to the same place or whatever. And then you just pipe it to your scanning and slam everything that's in those thousand assets, suddenly you've got some sort of outage happening on your internal network or whatever it may be. And I really don't think these are well thought out in our competitors' products. And that's something that I've honestly noticed is, you know, these safety elements that are really important to large enterprises or any enterprise, really. they're things that we've had to work out and systematically build in our platform. We have multiple different mechanisms of this, um, that we've had to build in the last six years. But I don't know if you agree with that. It's just generally, I feel that a lot of these, um, a lot of these competitors, they don't really understand these things and they may not understand them until it's too late, to be honest. Yeah.

MG: Yeah. I mean, it is kind of interesting when you look at, um, sort of, you know, the landscape, I guess, the overall landscape, you know, and the kind of care and attention that we put into it is kind of interesting, like to your point earlier, where, you know, they talk about use, but you're speaking about the feedback that we get, right? Where, where, you know, it where it's, it's very satisfying when they say that, right? They're like, if, if something comes out of asset note, I jump on it, because I know that it's real. Or, you know, in many cases, they just pipe it straight to the engineers to fix, right, that the security team doesn't even, there's so much trust in the security team doesn't have to look at it. And like, that sounds really good and really positive. But behind the scenes of that is a ton of work, right? And it's a standard that we're trying to, to hold ourselves to. So, so whether it's whether it's, you know, the, the, you know, signal element or the safety element, you know, there's a lot of work that goes into it. And so it's very validating, because and very rewarding, because it's like the combination of that. But yeah, I mean, to your point, And safety, I mean, safety is a very important thing, particularly if you're looking at it from an external attack surface perspective. I mean, we recognize that from the start, you know, in terms of, again, like, you know, the safety systems that we built to sort of handle different kind of attack surfaces and different kind of edge cases and different you know, configurations of an attack surface that could potentially lead to disruption if it was scanned, you know, at any kind of scale. I mean, these are the oldest systems in our platform, right? These were right from the get go, you know, when we were doing you know, very early testing of of Asset Note, you know, not only, you know, were we able to do this on bug bounties, right, but we will also, we're very fortunate to have a lot of very large companies that that we sort of knew that said, Hey, like, we're happy for you to sort of test this out against our attack surface. And, you know, these are sort of the things that sort of shook out in the first sort of few months of building AssetNotes. So they're the oldest systems in our platform. But it is a really important thing. But the one area, I mean, you touched on a few things, but I think the one area that also gets overlooked, you know, in this kind of conversation that we're having, is the design and the approach of the actual checks themselves. right? You have to think about safety and disruption in that as well. And so, you know, when you look at what we do, it's very curated, right? It's very curated in the sense that, you know, this is all built by us. It's using technology that's built by us. All of the checks are built and maintained by us. So, we take that kind of very seriously. And so, not only, you know, we've spoken about on other, you know, episodes, I guess, in the past about how we think about exploitability and how we think about the quality of that from a security outcome perspective. But to your point around safety, a lot of it is the design of that and how you approach that from a safe perspective, whereas a lot of tools that are just aggregating open source submissions, there's not really that standard there. And there's stuff that can slip through. And And, you know, that that can be a real problem, you know, if you if you just relying on that, because, you know, that I guess the, the draw of those tools is, oh, yeah, well, we've got, you know, 1000s and 1000s of submissions, and we've got, you know, 1000s and 1000s of checks. And so, so, you know, this idea that more equals better is not necessarily true, in a practical sense, if you care about these things. And, and if you if you are looking at scanning your external attack surface, you have to care about these things. Bug bounty hunters, I'll be honest, I think there's quite a few that are pretty blasé and gung-ho when it comes to scanning these programs' attack surfaces. So, they don't care. That's fine. That's on the program. But these companies, they do have to worry about this. This is their production internet-facing attack surface. Things going down is not is not, you know, can be quite impactful, right? It's not, it's not nothing, you know, that that can lead to, you know, significant loss of business and reduction of business and you know, disruption to operations and things like that. And so, so, you know, it's actually a really critical and important factor, which is why, you know, we spend so much time on it and have from the get go. But, you know, when you're when you're just getting something off the shelf, you got you kind of got to be a bit careful about that. Because, you know, often you're not getting that same kind of quality and rigor, because the people who are contributing to it, they don't care about that. It doesn't matter to them. Like it matters to us, but it doesn't matter to them. Yeah.

Shubs: And it's funny because given what's happening right now with CrowdStrike and everything, the fact is that these checks that are built in a lot of these open source tools, especially by the community, can definitely lead to problems. Maybe not a blue screen of death, but definitely problems in terms of their attack surface. There's a lot of techniques that are coming out as well these days that focus on things like cache poisoning and other things like that. And I've definitely seen where this can go wrong, where you actually just completely disable access to a website for a long period of time. So these are things that are definitely happening.

MG: It's tricky to get right. It's worthwhile doing it, right? But you've got to do it the right way.

Shubs: Yeah, for sure. And I guess, I guess the, you know, let's just say that you're an organization that's decided to build your own ASM, and you do all of this, right, and you get through all this monstrous effort that you have to do. Then you're still going to have to deal with some of the most weird shit you'll see on the internet ever. Like Mike, like I know we dealt with this and we're going to be speaking about it at B-Sides Canberra later this year, where we, we, you know, one day we just discovered that if you have any domains that point to a Chinese, um, hosted name server, then there's some real DNS poisoning happening there. And that just completely messes your results. And look, I'm not saying every organization has a presence in China, but any domain that even has a name server in China, even if it's Cloudflare, it's still completely screwed in this case. So there's, there's all sorts of things like this. And, you know, we've obviously done a lot of engineering around all of this stuff, but this is the sort of, um, I guess, experience that we have in this space that we bring into our product compared to others.

MG: Yeah, I mean, but I guess, you know, to some extent, that's expected, right? Like, there is a difference between a vendor product that you pay for, versus just, you know, open source, you know, tooling that you get off the internet.

Shubs: And I guess there are a lot of vendors that are masquerading like, yeah, just That's the interesting part where they are just gluing things together.

MG: So yeah, that's been kind of surprising to me, because, you know, if you're if you're a company, and you're like, okay, well, look, I'm just going to take some open source tooling, you know, maybe that maybe they understand all the things that we're saying. It's like, look, it's not going to be as effective. It's not gonna be that great. But like, it's good enough for what I want to get off the ground. And it's, you cotton, you know, cheap, right? You know, that's, that's one thing, right? But if they go in the opposite direction, say, well, hang on, I want I want somebody else to maintain, you know, this, I want somebody else to provide this sort of value that can do a better than me, right? That can do a better than just running open source tools, and then they go and pay money for a product. And like, it's just that behind the scenes, it's kind of, it's kind of nuts. You know, what, what extra are you really getting? And, and that's kind of, it's just disappointing to see. And like, I want to be clear that this is not the totality of the ASM market, right? You know, there are, you know, there are good products out there that that do try to approach things, you know, from a from a better perspective than just gluing tools together. And there's other different approaches as well. Some focus very heavily on manual work, which we've obviously are all in on automation. you know, as a more scalable and effective solution. But, you know, I mean, that's an interesting kind of approach, right? So it's not, it's not to say that like, that's everybody but us, but like, it's just so prevalent in ASM, right? There's so many sort of you know, me to companies that have just spun up, right? And, and, and they're just a thin veil over, over a bunch of open source tools. And it's why, you know, why would you, why would you, there's no value in that. You just, you're honestly wasting your money. And it's just, it's just wild to me how prevalent that is. But you know, that's just me, I guess, you know, like, we, we obviously build this stuff, and we obviously care very deeply about it. So I guess, I guess we're maybe a bit biased there. But yeah, cool. No, I think it's a good discussion. Yeah. And on that, on the, the DNS issues, the insecurity through censorship, we are presenting that at BSides Canberra here in Australia in August. So we won't give too much away. It's a pretty interesting issue. But yeah, is it August that we're presenting or is it September?

Shubs: It's the end of September. And I guess just for people who are watching, it's possible to exploit almost over 30 million domains on the internet through some client side attacks. And it's all really possible due to, we believe, some censorship protocols that are in place in China.

MG: Yeah. So I mean, Obviously, besides Canberra, if you're in Australia, it's a great conference, check it out. But, um, uh, you know, I'm pretty sure they record things, but maybe it's worthwhile after, after we do that presentation, uh, we might do another, another session here and like deep dive into it. Uh, that'd be maybe pretty interesting, but, uh, but cool. I think we can wrap it up there and, uh, yeah, chat soon.

‍