Get ready to embark on an enlightening journey with our guest, Huxley, a seasoned cybersecurity professional known for his extraordinary career path. From manipulating dial-up ISPs as a teenager, to landing a serious role in the field through a thrilling discovery, Huxley's tale will bring you to the edge of your seat. We dive deep into how he overcame fear and uncertainty while dealing with the unknown, and how he relishes the thrill of unraveling complex cybersecurity puzzles.
Our conversation spans the significant consequences of ignoring account management. Listen to compelling anecdotes underscoring the importance of disabling employee accounts after their departure. We also retrace Huxley's time at Cisco, discussing how the tech giant transformed into a security services provider. We also delve into the real-life repercussions of lax security practices, illustrating how even large corporations can suffer monumental losses.
As the conversation unfolds, we chart the evolution of cyber asset management. We further explore how Cisco expanded its security product portfolio and how Rumble Network Discovery transformed into RunZero. We highlight the necessity of securing all devices in an increasingly interconnected world, from office networks to personal devices and IoT. As a cherry on top, we'll delve into how RunZero assures complete network coverage, reducing the risks and reinforcing the importance of protecting an organization's attack surface. Tune in for a gripping and enlightening conversation about cybersecurity and asset management.
Affiliate Links:
NordVPN: https://go.nordvpn.net/aff_c?offer_id=15&aff_id=87753&url_id=902
Follow the Podcast on Social Media!
Instagram: https://www.instagram.com/secunfpodcast/
Twitter: https://twitter.com/SecUnfPodcast
Patreon: https://www.patreon.com/SecurityUnfilteredPodcast
YouTube: https://www.youtube.com/@securityunfilteredpodcast
TikTok: Not today China! Not today
How's it going, huxley? It's really good to finally have you on the podcast here. I feel like we've been trying to schedule this thing for quite a long time and I just kept on getting sick. I had a kid, I got a million excuses, but I'm really glad that you're here and that we could finally talk.
Speaker 2:Yeah, absolutely, joe, happy that we're finally doing this.
Speaker 1:Yeah, definitely. So. You know, Huxley, I always start everyone off with telling you know how they got an IT, what made them want to go into security. The reason why I do that is because there's a portion of my audience that is kind of in that boat right, where they're trying to potentially do a career change. They're trying to see if they can actually get into security, and I have found that it really helps everyone to kind of just hear a myriad of backgrounds. Right, I've done 150 of these episodes and I haven't heard the same background twice, you know, which is actually really interesting to me, because, going into this whole podcasting thing, I thought that I would hear you know the same one multiple times, but that's not the case, right?
Speaker 2:right, right. So I have two stories for you. One is the how I got into security and general story, and then the other one is how I got into it professionally. So the general story is just I was a teenager and I was hanging out with other teenagers and this was a time when you would do dial-up into ISPs and we would get on the internet and we had to find a way to get on the internet at a substantial discount. And so we tinkered around until we figured that one out. That's how that happened. Fast forward, maybe like five, six years, I got my first job off campus and I was helping out with the IT side, right, system administration, network administration. But one thing I also did was I decided to run a scanner, right, it was called Satan, which is you know long, long abandon. Where now, but you know at the time like it was the tool. And so I ran Satan on the network and I was able to find an unknown. It was either Telnet or FTP server on the president of the company's Mac. So apparently his like Eudora mail client if you remember Eudora, his mail client like would open up an FTP or Telnet listener for some reason. I forget what the reason was, but I immediately was able to raise my profile in the company because of my finding, and the president of the company decided to take me under his wing and mentor me directly. So that is an early example of how security really launched my career.
Speaker 1:Huh, I guess that's a situation where it can either go really good or really bad. You know they could go down the rabbit hole of like oh, you exploited this, you know you did this and get rid of you. Or they could do what they did and kind of mentor you and take you under your wing and immediately elevate you in the company. Is that kind of how you felt as well? Was there any debate in your head about oh, should I report this? Should I not Anything like?
Speaker 2:that, oh, I was young and not good at making good decisions, all right, so no, I just did it and I reported it and, luckily, the president of the company was very forward thinking and he appreciated that sort of hacker mentality and he went the way that it went, which is great.
Speaker 1:Yeah, when I was early on in my career as well, you know, and I started to get interested in security, I was really trying to get buy-in from the VP and from the developers to enhance our security of this product and I was having no luck and so I went down the path of literally finding a vulnerability, one. I had to learn vulnerability management, so I had to find this open source scanner because I had no budget or anything like that scan the product, find the vulnerability and then exploit it live in front of the VP, and he didn't know that I was going to exploit it live. I just showed him the vulnerability report and he goes oh no, those are resolved a different way. And you know, after some Googling I found the exploit right. So I just I was like, okay, well, I launched the exploit and it gets exactly what it's supposed to get. And I showed him and he goes oh, this is a problem. I was like, yeah, it's a big problem. This is like everything on this report is like this, where you know it's told, it's said that like it's resolved another way or whatever it might be, but it's not actually. And so we're running into these issues and I didn't realize, at the time I basically volunteered myself to own all of security for that company, which was an interesting endeavor. You know like my first little foray into security is like trial by fire.
Speaker 2:Yeah, yeah. So you know, one big upshot from that, aside from being imported by president, was that company wanted to start doing security projects. So every first firewall deployment they just handed it to me like go figure this out, figure out how to. It was just like an IP base firewall. But yeah, go figure that out. I'm like okay.
Speaker 1:Yeah, it's, it's always. I Mean it's a. It's a daunting task, right, I guess, for a lot of people, but it's also a great opportunity. You know, and I think people miss out on that opportunity because they're too scared or not not used to that uncomfortable zone, you know that area that it puts them into, and and there's been several times almost every project that I've taken on has been something that I knew nothing about, like I've never done it before, right, you know, you kind of know the gist of it, right, like how it would work or whatnot, but, you know, never logged into this tool or any of its competitors. But that's really like where you were in your paycheck, so to speak. Right, the ability to step into an unknown situation and kind of, you know, really master it, own it and bring it to fruition. Is that how you felt as well? Were you nervous when you're going through that?
Speaker 2:Oh, I was frequently nervous when I was told go figure this out. And when things weren't working Well, the customer was just like standing next to you watching you type. That sort of anxiety factor went through the roof and you just work through it and In my case, ultimately it worked out. But I will say one thing when I was that young I was really bad at determining Whether or not this unknown is something that I could overcome. Versus like this is way more than I can handle. As I've gotten more Experience, like I could better gauge the size of the unknown there.
Speaker 1:Yeah, I think that's a big thing as well is when you're early on, when you're young in your career, you're not able to gauge as easily what the what the work effort is like, what the difficulty level is, if it matches up with your skill sets, even remotely. And so I feel like early on, early on it's, it's important to take everything that you're offered and fail Quick, fail early, yes, you know, and get that through right because, like you said, right You're, you're in this situation where you have to deploy something and own a product at a customer right, and that customer is, you know, on your back, so to speak, right there, right there, you know, watching every move that you make, and maybe they're more intelligent or aware of this product than you are, and so they can sit there and be like, oh, he's making the wrong move, right, he's doing the wrong thing there.
Speaker 2:You know that that has happened. That has happened, yeah, but you know what? I think? Another great thing, following up on something you said, nothing that's really good about consulting security consulting is it forces you to into this practice of estimating effort and Forces you into this practice of tracking your time, so you get better at that sort of estimation as you get more experience.
Speaker 1:Yeah, that's a good point. You know, I was introduced to time tracking when I was working for a credit bureau and the manager that I was working under would just have us, you know, working insane hours on these projects. It was crazy the amount of effort and time that we were putting into it and the manager in between us and him got to a point when he said you know, I need everyone to just track their time because when I push back on him giving you these hours and whatnot, like, he Says that you're not working that much, when I know that you are and so we need to keep record of and track everything. And it was actually a very valuable skill. I thought that it was really tedious, that really dumb, that we were doing that and everything else like that right. But now, coincidentally, I do it at every other job as like my own safeguard right. Maybe I need to dial it back a little bit, give myself more time to recoup and rest and things like that right, like that's. That's now my mentality with it, because you know, in security you can I mean, you could literally just work 24 hours a day and not run out of work.
Speaker 2:Oh, that's the problem there are more vulnerabilities than anybody could ever remediate. That's, that's a hundred percent true.
Speaker 1:Yeah, I mean that's just talking about, you know, on-prem right, like when you say that, I think of on-prem vulnerability management, but when you add in the cloud, I mean that's tens of thousands and that's.
Speaker 2:It's changing all the time. Right, because right developers, other engineers, they have the ability to spin things up and down all the time. So you know, whatever point in time snapshot you have of vulnerabilities and and that attack surface like it's, it's already wrong by the time you look at it.
Speaker 1:Yeah, which is? I mean that that's like the most challenging part of it Am I at my current job, we do like a daily report. It's a daily scan, the report goes out right and it's always challenging, you know, from the aspect of when you start including dev environments Into your overall reporting of the numbers and whatnot. It's like, well, the developers need a place to play. Yep, if this dev environment has no connection to anything else, what does it really matter if it has 50 critical vulnerabilities? Right, because there should be no customer data in there or anything like that should be being the the operative word there.
Speaker 2:You know, yeah yeah, but we have seen examples where dev environments were part of the attack chain. Right, they weren't that the end goal of the adversary, but they were able to laterally move Through that dev environment to get to something that's that's more valuable. So you could say that, but you know you're leaving yourself a gap there in terms of in terms of your defense. And I'll say another thing about devs. There's also been documented examples where dev credentials were used, again to production environments, right, right, certain devs do need to get into production environments to do Some sort of troubleshooting and if those are not properly Decommissioned, when that developer leaves, like that's, that's another attack vector. So dev environments are totally Unscope as far as I'm concerned.
Speaker 1:Yeah, that's you. You bring up an interesting point. You're always taught, right, as soon as someone leaves the company, you should be disabling their account. You know, immediately, right, that's just good practice and Sometimes it's hard to keep track of that, to keep the checks in place, right, to make sure that people are doing it and whatnot. And A friend of mine he works for a different company, a company I've never been a part of or anything like that, I won't name them but he said that a former, you know systems engineer had left the company under what seemed to be good terms and Apparently he had some issue, you know, with the company or with some product or whatever it might be, and that's why he actually left. But he didn't tell anyone that. And two months later I mean, this is literally months later like, this guy already has another job and everything like that, right, mm-hmm. Months later he gets bored and he starts hacking the environment using his old account and Getting into places that he shouldn't be getting into and downloading data that he shouldn't be, and it took them Maybe a day right, to figure out who was doing it, where it was coming from, that sort of thing. But the damage is still being calculated. You know like they still don't know absolutely everything that that took place. Maybe he did actually use that account within those first two months and they're just now seeing it. It's a complex problem to solve.
Speaker 2:Yeah, the example I was thinking of was this very large company that has an online meeting product and the developer left and many months later, that person's credential still worked and he logged into the production environment and just started taking down servers that supported this online meeting product. And the company explained it in a way as they were doing some like chaos engineering testing, but ultimately it came out, and not only there I don't know what the dollar amount was, but some humongous dollar amount of damages but on top of that there was a lot of reputational damage because the CEO of this company had to go on Twitter apologizing for the outage. And it was more embarrassing because the CEO at one point said, okay, it's all fixed now, and then somebody else posted another tweet that says no, not still not working. It's just like, both quantitatively and qualitatively, like that was a very expensive breach and it could have all been prevented if there were the proper governance for Dev permissions.
Speaker 1:Yeah, that reminds me of kind of what happened with the last past breach. You know, september of last year they were claiming oh, no one's vaults were leaked or anything like that. They didn't get any customer data. It was just this other small subsection of data that they got. A couple months go by, and you know, the update is oh wait, they have everyone's vaults, but don't worry, you know they can't get into it, it's encrypted this way. And then a couple weeks later it's like oh wait, they can get into everything. It's like guys you make one one you know report right, tell us the truth the first time around, because now it looks like you're lying.
Speaker 2:Yeah or incompetent. So which one's worse? I'm not sure.
Speaker 1:Man, insecurity, probably incompetence. So you know, just looking at LinkedIn, I saw that it kind of seems like you started your career at Cisco, right, how was Cisco? How was that time there? And I asked, because Cisco is such a large company, right, and especially, you know, even during the years that you were there, I mean they were, they were everywhere, right, and they still are everywhere. They're a huge part of the network stack for a huge percentage of the companies in the world. So what was it like to you know, work for that company and learn? Was it heavily siloed? Was it more open space? How does that look like?
Speaker 2:Yeah, I would say I watched Cisco go through this transition from a long time ago where it was really route switch focused and a lot of the motions within the company were really focused on that. So I was there to witness the formulation for the first time of the security services division, for example. So building up capabilities around delivering security services both on the offensive side as well as the defensive side, and things like this, and now like it is a part and parcel for the company, even with the products, of course right Products and services. So it was a really great transition to watch. I mean, cisco was already a mature company but it matured on the security side while I was there.
Speaker 1:Yeah, absolutely. You know, it's always interesting, right, when I don't look at Cisco products that often the reason is because I'm not a network engineer. I'm not even a network security guy, right? So thankfully I do not have that headache, because when I was trying to get into security I was studying for the network plus and that book would just put me to sleep every time, right? So I'm like, okay, networking probably isn't for me, right? It's interesting to see how the products have changed over time and how their own I guess product stacked or product offering has changed over time and how they've added in this umbrella, you know, overall of your security services and everything else, right, to provide that enhanced visibility and as few screens as possible. When I do check it, I'm looking for, you know, changes like that, which I always find is interesting from a larger company, right, just to see how it works, how they grow and things like that.
Speaker 2:Yeah, certainly they've grown in capability and at one point they just had a firewall, but now they have like over a dozen security products.
Speaker 1:Yeah, yeah, it's a huge portfolio. I mean, just the team to manage their portfolio is probably bigger than most companies Like. That's how I feel, at least. So, fast forwarding a little bit, going through your background and whatnot, I see that you, you know, we're the head of security over at Datadog and now you're over at RunZero. Yes, so talk to me a bit about RunZero, because I feel like it's a newer company on the market that not many people have heard of, but the capability that your solution provides may be actually pretty unique in the space.
Speaker 2:Right, so it's actually not that new of a company, because we changed our name about a year ago. We used to be called Rumble Network Discovery, which I think a lot of folks still think of us with that name. Runzero is a more recent name that we had. And you're absolutely right, the problem that we solve is actually a very old problem. It's CIS control number one. For those who are familiar with the CIS controls and this actually kind of goes back to me running Satan back at that really first company that worked at off campus and we're solving the problem of asset inventory. This is the very, very basic tenant of you can't protect what you don't know about, right, and so tracking down those unknowns on your network is absolutely crucial if you're going to have a credible defense. And the thing is that problem cannot be solved with tools like Satan anymore, because 20 years ago, 25 years ago, we in security were asked to protect the office. Basically, right, you got your desktop and on your desk in your office and basically everything was there and you could even get away with edge protection. Right, just throw up a firewall and maybe you can get away with not having any sort of endpoint protection, because you're protecting the perimeter. Now that's changed. That has changed entirely. Right, you are now being asked to protect not just the office but all of those devices in the cloud and all the devices that have left the office and gone to the coffee shops or to remote employees homes and, aside from that sort of diversions, environments. But there's also been other things that have happened, like the rise of bring your own device, for example, so you have all these devices showing up on your network which you may not even manage. There's also the rise of IOT, right Building, automation and things like this, smart speakers, which we didn't have 20 years ago. And then, finally, there's this convergence of IT and OT. So many security teams are now being asked to manage the factories or the water treatment plants or the medical devices in addition to the traditional IT devices. So you need a modern tool to handle this type of cyber asset management. You need a modern tool to go and do that type of asset discovery. And what I'm finding is a lot of folks think that some of their current tools that sort of does some sort of asset discovery on the side. They think that those are good enough, when in fact those tools are really not addressing the unknown, unknowns in your network. They don't find those unmanaged devices. And even if you think, okay, well, with my existing tools I can have like 95% coverage of the devices that I have, it doesn't mean that only 5% of those unknown devices only have a 5% negative impact on your security posture, because those unknown devices actually have an outsized impact on your security, like those are the ones that the adversary is going to go for. They're not going to go after the devices that are up to date on their patches, that already have an EDR on it. They're going to go find that one device that you have that's been sitting there in the corner, that's not been up to date because nobody knows what it does anymore, and they just sit there and they lurk on that machine for as long as they need to to do further reconnering or to find the crown jewels. And so people think, oh, I have my EDR, that's that's my acid inventory. Or I have my, my volumet scanner, so that's my acid inventory. Or have my NAC and that's my acid inventory, when in fact those solutions, when they do acid discovery, are optimized for managed IT devices, not those unknowns on your network that are going to matter more to you. Those are the the critical attack vectors.
Speaker 1:That's interesting and it's very indicative of where the market has gone post COVID right. Is there a way that your solution is able to say like yes, we do have 100% of the devices in the network? The reason why I ask that right is because there always seems to be some sort of like gray area right when it's like okay, I think I have everything. And then, of course, another 200 devices show up and it's like oh, I didn't include this, I didn't account for that. Is there? Is there a way to have some sort of assurance behind it right? Because even as an engineer that would set up a tool like that or I'm talking about setting up like a vulnerability management scanner, which you are not, it's more than that, you know, there's always that gray area where it's kind of hard to tell if I got everything.
Speaker 2:Yeah.
Speaker 1:Is there a way to do that with your solution?
Speaker 2:It's always going to be difficult to tell right. But the question is how much can you reduce that unknown Right? Are you bringing it down to zero or as close to zero as you can? And so that's where we're going after there. It's never going to be 100% Right, because the moment you go and create an asset inventory and then somebody brings in a new device onto the network, it's already inaccurate, it's already missing that device, even if the next discovery you know there's a cadence for the discovery, even on the next pass of discovery is a minute from now, for that minute you're missing that one device that somebody brought in. But what you want to do is try and make that as complete as possible, and that is something that you're not going to be able to do with your EDR or your phone scanner or your CMDB discovery or anything like that.
Speaker 1:Yeah, that makes sense. So let's talk about more of how it does what it does right. So is it just sitting there waiting for advice to reach out to the network? What is it actually doing to determine the CMDB?
Speaker 2:So there are three approaches with RunZero for doing this. The first one is integrations with all the other tools in your IT and security stack. So I talk about how, like EDR and phone scanners are not great for ass discovery, but they're really good for the jobs that they're meant to do, right? Edr is great for endpoint protection, phone scanners is great for hunting down volans in the network, so they do have a lot of valuable information, and so you want to bring all that information in, and we could do that with integrations. And, frankly, you know any sort of scanning technology would miss anything that's disconnected from the network. You know devices that are in remote employees' homes, so you're going to need those integrations anyway. So that's number one a wealth of integrations that can pull in data from all these other solutions in your tech stack. The second way is with an unauthenticated active scanner. So this would be strictly finding the things that are on your network, but also it could scan like the external surface of the cloud, for example. And what this is is unusual, because most scanners out there most network scanners they tend to require credentials because they try and log into these devices to get more information. But if you know the credentials about those devices, then that means you probably already know about it, you probably already manage it, you probably already protect it, so it's not really helping with this unmanaged device or unknown unknown's problem. So you want to go with something that doesn't require authentication and yet can find lots and lots of detail, and so this is where things get really interesting with the scanner is that when you take an offensive approach or the view of the attacker to go out and recon the network, but for defensive purposes, you actually get a lot of information. By going through and looking at all the ports, all the listening ports on the device, you can actually get a lot of information that would be typically more interesting to a security researcher and then use that to come up with a really accurate identification with the device, so like you can achieve really accurate fingerprinting even though there aren't credentials, and so that's very interesting. That's a lot of folks find that to be one of the most interesting things about Run Zero. But there's a wrinkle here. When you look at some of the other unauthenticated scanners, the way they're developed, they're not really safe for fragile IoT and OT devices, so they have a legacy of crashing those devices. So our unauthenticated active scanner has actually been tested and proven in those types of environments, so it's safe. So a lot of folks they assume that, like we're end map on steroids is how I've heard people describe. It is actually not true. Like this was actually developed from the ground up by the same guy that wrote Metasploit, in fact, and so that's that's approach number two. And then we have a third approach that is being released next month and this is a passive discovery approach. So there are some environments where they simply do not want to do any active scanning whatsoever and there are no integrations for those types of devices. So typically this is this will be an OT environment where they just either don't have the time windows to do scans or they just don't want anything touching those devices, and so for that we have this passive discovery capability where we're able to sample the traffic that comes in from a switch and then use that for discovery and fingerprinting purposes.
Speaker 1:Oh, that's really fascinating. That is a challenge that I have faced before, where it's an OT environment and people don't want the scanning to impact the device or really even touch it in an effort to ensure that it isn't bogged down and whatnot right, and no one really has a good solution for that. It's always kind of like we won't know it's there unless we touch it. Right, we have to scan it and everything else.
Speaker 2:Yeah, there are ways around that, though. There are ways around that, I mean, there's there's multiple things going on here, but I think one of the more important ones is the use of incremental fingerprinting. So what you would do is you would send a super benign query to a device and just to get some macro sense of what that is, and then you would follow that up with successive queries that gather more detail, and as you do this, you're building out more and more of a picture of what the device is. And what you could do is you could say OK, based on what I know now, this code path is safe for this type of device. This code path is not, and so you adjust the queries that you send based on the information that you have so far. And that's just one of the principles of Active Scanning and OT.
Speaker 1:Oh, wow, that is really interesting. So is it doing this over an extended period of time? So like, let's say that you're scanning an OT device, right, and it does its first, first poll of that device, right? Is it then, let's say, in the management console? Is it then going to say like, hey, you know, we'll know, we'll have a better picture of this device within you know, two days or three days, whatever it might be, because you're spacing out those polls?
Speaker 2:No, no, it's not over days, it's over seconds.
Speaker 1:Oh, wow.
Speaker 2:Right, and it's not even in the console. So there's a piece of software that's called the Explorer and that is sitting on some host that you would provide. Right, the entire solution is software. There's no hardware component to the solution. That. That's provided by the company. Like you, the customer, you provide the hardware for it or the virtual machine your pick, and you deploy the software that's called the Explorer and it itself has that logic that can do that incremental fingerprinting.
Speaker 1:Oh, that's interesting, that's, I mean, that's a new way of thinking about this problem and kind of attacking attacking this problem, so to speak.
Speaker 2:Yeah, yeah, for sure. And there's there's other things that you would do when you actively scan OT. That that's really important too, but I think you know to your point this this is the most relevant principle out of the five. Yeah, absolutely, but but again, if active scanning is not not your cup of tea, then there's also this passive traffic sampling capability that's due to be released soon.
Speaker 1:So where do you see the space going? Is it still growing? Is it still evolving? Because the reason why I ask right is because for a while there we didn't see a whole lot of innovation from competitors like Nessus and Tenable and Qaulis right, that were kind of legacy solutions in this space, and now we have solutions like yours coming along that are kind of revamping and remapping what it means to be this type of solution. Where do you see your solution, your company, going for the next couple of years?
Speaker 2:Yeah, so there's, and there's many ways to go about this, but I what I can tell you is the problem is not going to get easier. The various attack surfaces that organizations have, they tend to grow. It's rare that an organization's attack surface is like just goes away or or gets smaller. There tends to be more and more devices connected to the internet every single day, so the problem is just going to get worse. And volun scanners play a very important role in protecting organizations. Right, you do need some tool that can execute security probes on devices to verify if a vulnerability exists. Right, and that's part of it. But another part of dealing with the attack surface is identifying insecure configurations. Right, the fact that Telnet is running on a device, or the fact that there's an SSH server that does not limit logins to public key but allows password, for example, that is not a vulnerability with a CVE attached to it, that is just an insecure configuration. And so when you are trying to protect that attack surface, you got to look beyond vulnerabilities. There's vulnerabilities, there's insecure configurations. And then there's also the context that you would want around the asset itself, like what is this thing? Is it important to my business? But also, network location Is this device externally facing? Does it have a public IP address that's reachable by the attacker, right? All those things help you truly understand what is the risk of that device. And then if you're able to categorize that device by the attack surface that it contributes to so let's say, this is a phone, so this is probably part of my mobile attack service, or if this is an EC2 instance, so this is probably my cloud attack surface so when you're able to take all of the riskiness of that device and secure configurations and vulnerabilities and that context around it and then assign it to an attack surface, now you have a really good picture of how well you are doing in protecting your organization on that attack surface and then you can start actually prioritizing where the work should go and you can measure how well you are doing in terms of reducing your risk in that attack surface.
Speaker 1:So you bring up an area that I always felt like was lacking in the space. Right, it's kind of more focused around like those known vulnerabilities, the CVEs and fingerprinting things based on that. But, just like you mentioned, not everything is going to have a CVE. It could be poorly configured and opens you up to maybe not even a zero day, but just an exploit of a service, a different way than what was fingerprinted before right, yeah, yeah, like I like to say.
Speaker 2:vulnerabilities it's the vendor's fault. Insecure configurations that's your fault.
Speaker 1:Yeah, that's proven out in the cloud, right. That's a really good example.
Speaker 2:How many S3 buckets are publicly accessible? There's still millions. It seems like every time you hear about like a new data breach in the cloud, like there was some open S3 buckets somehow figuring into the picture and was like do we never learn, Do we never?
Speaker 1:learn. Yeah, it seems like we don't. Probably because we're so focused on the tools that we have in front of us that are not telling us that you know, Mm-mm. That's the thing.
Speaker 2:We're too reliant on the tools in some ways, potentially, and we're not thinking outside the box enough, or we just don't have a good handle on what are all the environments that we need to protect and what are all the different devices and assets that are in there. That's a big contributing factor too.
Speaker 1:Yeah, that's a really good point. I mean, that's a huge part of it not having a good handle on your environment. And it's funny. I worked for a company fairly recently and the security manager would always complain when having a CMDB was not on the must have projects list for the year, you know, and he had been requesting it for the last like seven or eight years. Yeah, and it would always come back to that thing for him. He goes how in the world do I know that I'm protecting everything in this company if we don't have a CMDB? So we don't even know what we have. We just kind of assume that we're able to protect it all.
Speaker 2:Yeah, and it doesn't necessarily need to be a CMDB like a full on like CMDB, like it could just be some sort of asset inventory that comes from cyber asset management solution. In fact, for RunZero, one common use case for customers is to take the data that was discovered by RunZero from those three different discovery approaches and then importing that information into the CMDB. For other reasons, Right, Because the CMDB itself is fine and the sort of ITSM workflows on top of the CMDB, like that's all you know, top notch. But the default discovery component that comes with the CMDB tends to not do a very good job of discovering devices.
Speaker 1:Yeah, that is very true. I used to work with a solution that would claim that they can have a CMDB and once I started to do a deep dive into what the solution was actually doing, it was just end map. It was literally normal end map commands. I'm like, guys, come on, I can do this myself. You're not doing anything special, You're not doing anything unique here that we aren't already doing. It's an interesting space to see, continually evolve. I always felt like when I was in the area of specialty with this right, I felt like the area was stagnant. But it's nice to see another company come along that approaches the problem a different way.
Speaker 2:Yeah, it's an old problem with some newer ramifications of course. And to take on those newer ramifications you do need to have a modern approach to the problem. You can't just run end map necessarily. End map was released at like, like DEFCON 8 or 9 or something. Yeah, so that would have been like the late 90s.
Speaker 1:Yeah, well, you know, huxley, we're unfortunately running out of time here for our episode. But before I let you go, how about you tell my audience where they could reach out to you if they wanted to reach out to you, and where they could find Run Zero?
Speaker 2:Sure, yeah. So I'll start with Run Zero. Just go to runzerocom. There is a free trial where you could try out all the different features, but there's also a free forever edition. So you start the trial and it downgrades the free forever edition, which is really great for doing discovery in your house or just to tinker around and to try it out. To start the trial, you don't need to provide a credit card or anything like that and no sales person is going to call you, but you're welcome to just like try it out at home and see if you like it. For reaching out to me, my name is Huxley Barbie. You can find me on LinkedIn, you can also find me on Twitter and you can also find me on the Infosecexchange instance for Macedon. So LinkedIn, just look for my name, huxley Barbie, and Twitter, it's at Huxley, underscore Barbie, and then on Infosecexchange it's just at Huxley, but I'm sure you'll provide the links in the show notes.
Speaker 1:Yeah, absolutely Well, thanks, huxley, and I appreciate you coming on and I hope everyone enjoyed this episode.