Risky Business - Risky Biz Soap Box: Why Azure vulns should get CVEs

Episode Date: March 21, 2024

In this Soap Box edition of the podcast Patrick Gray talks to Nucleus Security co-founder Scott Kuffer about whether or not cloud service vulnerabilities should get CVEs, what on earth is happening with NIST’s National Vulnerability Database (NVD) and more.

Hey everyone, and welcome to this special Soapbox edition of the Risky Business Podcast. My name's Patrick Gray. These Soapbox editions are wholly sponsored, and that means everyone you hear in a Soapbox podcast are paid to be here. And today we are chatting with one of the founders of Nucleus Security, Scott Kufa, who many of you would have heard on the show a bunch of times over the years. Nucleus makes a vulnerability management platform that can do things like ingest data from multiple vulnerability scanners that are present in your organization. So, you

know, you can take all of the scanner output, put it in one place, normalize it, and then from there you can slice and dice it, prioritize your remediation efforts, plumb things through to tickets, to Slack, figure out who the owners of some of these vulnerabilities are, and so on. So yeah, I mean, that is a massive oversimplification of what they do, but that is the general gist. So Scott is very much an expert in vulnerability management. So Scott and I recorded this interview last week, and we talked about things like whether or not cloud services like Azure and AWS, whether vulnerabilities in those services should get CVE identifiers.

So that's been a bit of a topic lately. We spoke about what on earth is going on with the National Vulnerability Database, the NVD, which is maintained by NIST. And we also spoke about things like, you know, what China's National Vulnerability Database, the NVD, which is maintained by NIST. And we also spoke about things like, you know, what China's National Vulnerability Database is doing, and a bunch of other stuff too. So I'll drop you in here where Scott is talking to me about whether or not he thinks cloud vulnerabilities should be assigned CVE identifiers. I hope you enjoy this interview. Yeah, it's a great question. And I know the topic last time when I was here was we were starting to talk about like, what's vulnerability management's purpose in a new modern world, right? Like, you look historically about, hey, CVE, patch,

network security, you're on your way, right? But there's these huge transitions to new technologies and how you actually manage risk within these different paradigms and environments. And, you know, this has been honestly a conversation as old as time where you're trying to figure out like what actually is a CVE? Like I remember even distinctly doing research on this and it's, you know, this is the exact same conversation from 1998 when CVEs were first coming out, which is like, what's the boundary here, right? I mean, even we look back a few years of the MongoDB, like just default password craziness that was

going on, right? Do you count that configuration, the default configuration as a CVE? Yes or no, right? But we're taking that and we're blowing it up to a huge level because cloud is so replicable in so many different areas. Like if you mess up a Terraform deployment configuration in one spot in your cloud environment, it's going to replicate to your entire cloud environment potentially, right? And so I would say there's still no clear agreement on that. I would say that a lot of organizations and industry experts are now leaning towards, we need a way to track those. And if it's not CVE based, then there should be some other identifying force that we can use to track unique configurations across cloud so that you can at least share information, right?

So we're kind of back to square one in a lot of ways. Well, I mean, so I've completely done a 180 on my opinion on this, right? Like, as I've said on the show before, what's the point of having a mind if you can't change it? I used to think cloud vulns shouldn't get CVEs because, you know, CVEs are kind of used for tracking and whatnot. But then, you know, having had a bunch of conversations with people about this, I give you an example the the the microsoft incident in which their signing key was extracted okay so that's not a cve if someone obtains

keymat but then it failed to respect the intended boundaries right so you could all of a sudden use this consumer signing key to sign tokens for corporate email access. That's a vulnerability. Like if you had found improper key validation in a standalone product, like that would get a CVE, surely. Probably so, right? Yeah. So now I'm thinking, well, why would we not then catalog that somehow? Because that would allow users of that service to sort of understand their risk a little bit better, which is this condition existed for a while, does it have any impact on us? So I think some sort of central cataloging of these types of issues, I used to think it was a bad idea. Now I think it's a good idea. Yeah, it's a fascinating one to a degree, right? Because you immediately start going down this path of configurations can be so widespread and different, kind of slightly different. And so you have to figure out what the box looks like.

And so the way it normally is handled right now is, you know, like CIS benchmarking or like, you know, PCI configuration audits, like there's all these different auditing type solutions that actually you can get from vulnerability scanners oftentimes too, or even some of the new CNAPS tools, right, like your Wizzes and Orcas and Laceworks of the world, right? And, but they're like broader categories of, of things, right? It's a, hey, you have this misconfiguration and it's tied to this control in this type of compliance framework or configuration framework. And it's not super specific. And so it's like, yeah, what is the boundary of what makes that a CVE or what makes that a vulnerability in the traditional sense?

And then I think there's a second question, which is me as the user, when you think about a traditional CVE, generally it's a, hey, we need you as the company to go do some sort of action that results in either changing your software to mitigate it. This is the argument against, right, which is the side of this conversation that I fell down on, which is that a CVE is designed almost like a ticket, right? Like it's an action item for people to go out and do stuff with. But in the case of cloud, obviously it's the cloud provider itself who will do that. Ergo, ipso facto, no CVE is required. That's the thing that I now disagree with, but used to agree with. Because I'm a flip flopper. Scott, what can I say? And that's what we appreciate, Patrick. We appreciate that. There's not enough of that in the world. Maybe you can change my mind on this one too. We'll see. But yeah, so it is one of those ones where it's like me as the vulnerability analyst or as the company, what am I supposed to do about this, right? A CVE gets issued and it

affects the cloud provider, but I'm impacted. How am I supposed to respond? Because oftentimes, there's not really even a lot of mitigating controls you can take. I mean, sometimes there are, but then sometimes there's just not, you're just there and you have to accept it. So is it more like a GRC risk item that you just have to kind of accept the risk on? So how do you manage it? This is the bit where I eventually changed my mind, right? Because I think once this stuff, you know, if this stuff were to be centrally cataloged, instead of sort of swept under the rug often, let's be honest, then it would allow CISOs or vulnerability management types to actually sit down and say, okay, this condition,

this vulnerable condition existed in a cloud service that we use for a period of time. Could something bad have happened as a result of this condition? You know, there's your action item. So, you know, you might have something to investigate. Or further, now that we know that these types of conditions may occur in our cloud service providers, what other mitigating steps do we need to take so that if this happens again, we're better protected? Or, you know, we might want to instrument a detection

based on the idea that we know that our upstream supplier makes these sort of mistakes now. So I think a CVE is useful for more than just remediating a specific bug, which I know is how volume management types would think of it. But I'm just saying at a higher level, this sort of information has other uses as well, which is why I've sort of gone pro-cataloging it. Yeah. And you know, I totally agree with you. And if I'm going to be totally honest, I think that the hesitation from the VM types for this approach is actually a fear of how do

we actually operationalize this, right? It's like, yeah, we already are struggling with just pure patch management style vulnerability management. But see, I think that's what skewed the conversation is it's, it's, it's not data that you would necessarily operationalize, but it's stuff that you would, that, that gives you context, you know?

Absolutely is. But I mean, I actually have this whole, this whole thing that I've been, I've been on the soapbox with perfect timing, right? I've been on the soapbox recently about how, just how we think about prioritization as a vulnerability or like industry just doesn't

really work in the face of reality oftentimes. And I'll give you the example that I always give is that, you know, when you're looking at prioritization of vulnerabilities, you as a defender are normally thinking in terms of like a list of vulnerabilities, right? It's like, hey, like we have a list of vulnerabilities and then the one that is the highest risk, you know, whatever that means to you is at the top of the list and we work our way down the list. But then when you try to operationalize that in a normal business, that's not how businesses think. They don't think in terms of help me identify that one most critical item. They're thinking in terms of, hey, well, we do patch Tuesday and we want to patch as many things as possible. We have efficiency that we have built into our system.

We have product management processes within our AppSec cycles to actually deliver as many vulnerabilities as possible. And so you actually have two kind of competing prioritizations. As many fixes as possible, I think, not as many vulnerabilities as possible. Correct. Yes. Yes, exactly. Thank you for holding me accountable to that one. You don't want your product teams delivering as many vulnerabilities as possible. But anyway, go on, Scott. That's correct. Good points. You know, although it depends on the vendor that you are, we're not going to mention any names. Whoops. So I think that ultimately, like, we're looking at that reality, right? And then we're looking at the, oh, and by the way, we want to add more work to that reality.

But in that paradigm, right, you're looking at, like, vulnerability managers, their role starts to which is working with engineers, working with remediation teams to figure out what should get fixed kind of in the context of these little units inside of a business, whether that's departments, teams-based, whatever it is. And so, but there's just not enough VM people to do that appropriately, right? So it's just not a realistic option for a lot of organizations. So when they're looking at adding a whole new field of managing risk,

I think it just overwhelms a lot of people. So that was a long-winded way of saying I think people are overwhelmed by the idea of adding more stuff. Yeah, no, I get it. And it totally makes sense because we don't have an infinite workforce, right? We just don't have an infinite workforce.

And this is not a problem that is specific to security. You know, I understand in the United States at the moment, it's very difficult to do large-scale construction projects because there's a big shortage of people with certain trades and skills, right? Like it is not just a security-specific phenomenon. But I do wonder, don't you think it should be a CVE, you know, Microsoft, you know, failure to validate user context, you know, as part of the authentication process. Shouldn't that be a CVE somewhere? I mean, I believe I'm on that side of the argument that it probably should be

like we as my belief, obviously, I own a data aggregation company all around vulnerability. You want all the data. I want all the data, right? But the more data that we have, the better kind of information and visibility we can give you. And you know, like, that's, that's just where we sit on it. Like we want as much information as possible because back to our fundamental thesis, all the information you need to do your job as a VM organization is there. It's just not easily accessible or there's just way too much of it to actually to do the thing.

So yeah, I totally am on the same page as you, but I'm sure we'll get comments. Oh yeah, yeah. It's funny that something so like, you know, in the weeds nerdy actually gets people so fired up. Now, look, let's move on to a different topic, right? Which is, you know, as you pointed out, people are having a hard, hard enough time already dealing with the current sources of vulnerability information that are out there. And it turns out some of these sources also that we're all dependent on are a little bit less than reliable. Scott, I understand from what you've told me that NVD, which is the National Vulnerability Database, which is an extremely important compendium, an extremely important vulnerability database, is just not updating at the moment. Why is that? And when did it stop

updating? Tell us all about this. Yeah, there's a lot going on in the VM space, everybody. So if you're not paying attention, now's the time to do it. So NVDeep is the main kind of catalog that we all agreed upon a long time ago to be the unique list of vulnerabilities out there so that we could all communicate about what vulnerabilities are going on out there in the wild. And like, I see this, then I can send that to somebody else and they can see it and we can all talk the same language. Well, that is a government, US government funded program, right? And so it's run by NIST. And as of, I think it was February 11th, around that time, there's all these services out there that track basically the number of submissions to NVD and then the number of those that actually become CVEs over time. So the same day that there was a banner published on the NVD

website that basically says there's going to be huge delays in assigning CVE numbers because NVD is trying to establish a consortium, whatever that actually means. They're trying to establish a consortium to address challenges. So a lot of vulnerability experts are really freaking out because they have no idea what that means. They haven't been super clear. But from everything that we can tell, they're only actually updating a very small number of CVEs at this point. And those are generally ones that end up on the SysEcev list. So everybody is starting to wonder what actually is going on. But it begs this bigger question of a lot of vulnerability scanning technologies

are actually built on the NVD database in order to kind of deliver consistent results. And so people are starting to wonder, well, what does that mean kind of over the longterm or if this continues for an extended period of time? So it's pretty interesting. I don't think this has ever actually happened before, at least not as long as I've been in the industry. So yeah, we're not really sure what the impact of this is going to be.

I mean, it sounds like the communication from NIST on this, not to be too crass, has been pretty piss poor. I mean, I haven't seen any communication other than the banner at the top of the website that just says that basically their stuff is super delayed and we're establishing a consortium. So, I mean, I don't know. That would substantiate my categorization of their efforts, I think, Scott. Yes, yes. Non-existent, I think, would probably be the word, the phrase I would use. But yeah, it's fascinating, right?

Like a lot of people are freaking out, right? If you can imagine like you're over at Tenable or Qualys or whatever, or a lot of the EDR vendors that are doing CVE scanning now, it's like, okay, well, does that, what are you going to do? Like what actually is your step forward? How are you going to build signatures for CVEs

if there are no CVEs? Yeah. I mean, that's a good question, right? So what is the process? Stuff goes into NVD first and then MITRE might take a look at it and then assign them CVEs? Or how is CVE BABY formed these days? Yeah.

So it's pretty fascinating. So there's these associations or organizations that get assigned a license to be something called a CNA, which is a Certificate Naming Authority. And basically, they review submissions. So anybody can submit to the nvd website or whatever and generally it's vendors like so if microsoft finds out that they have a bug that results in a cve then they are proactively going to submit that cve to uh to the nvd uh or cisa or whoever and then it gets routed uh effectively and then there's a an analysis process that is this cohort of folks that are from cnas that will go in and they will effectively or CISA, or whoever, and then it gets routed effectively. And then there's an analysis process

that is this cohort of folks that are from CNAs that will go in and they will effectively assess and provide and say, yes, we've confirmed this is a CVE. We're going to run it through all the CVSS scoring stuff that they want you to have with it. Now they've got the CISA KevList type information. And then they basically push a button and it publishes out to this JSON feed that you can consume on the internet or- But the NIST database, I mean, it has stuff in it that hasn't been assigned a CVE, right? Yeah. So that's called a reserved. So there is kind of these different states and sometimes they're rejected as well. So to be clear, the NVD is not probably all vulnerabilities in existence. It's just all the ones that NVD could like, we could agree that it is a vulnerability. And so that's why you have

a lot of these products. I mean, it's always been, you know, I've always felt a bit sketchy about NVD, to be honest. I've just never felt that it could be trusted as being like a comprehensive set of data. And it just seemed like the whole thing seemed a little opaque. But anyway, that's a whole other conversation. The point is, over the last, what, decade and a half or whatever, NVD has become something that people really do regard as authoritative. So I imagine having it fall over at the moment is pretty bad. It is.

But yeah, we don't know really what the impact is going to be, right? Because obviously, like, I don't know all of the tools out there that rely on NVD. But I mean, there's a ton, right? If you think about even just like vulnerability and threat intelligence, right? Like we've got these threat actors that they're, you know, they've got malware out there in the world. And a lot of them are leveraging exploits. Are those exploits tied back to a specific vulnerability so that you know what patch to run? Like probably. Are those exploits tied back to a specific vulnerability so that you know what patch to run?

Like probably, but NVD and the CVE number tends to be the kind of glue that stitches all that together in the modern vulnerability industry. So it's yet to be seen like how we're going to adapt if in a world where CVEs are hard to come by, which it looks like we might be for a little bit. Well, maybe the Chinese will help, Scott, because they have launched their own NVD. Yes, the CN NVD. It's a beautiful, beautiful thing. Obviously, I think it's been around for a while. There's obviously lots of question marks about it because they don't publish every CVE that they find, right? They reserve a lot for their ministry of defense column activities,

special activities that they, that they do. So. But that sweet bug from the Chianfu cup might not find its way into the CN NVD, you know, immediately, you know, maybe on a bit of a delay for some of them. That's right. Yeah. And so, but that really is the, the only other kind of call it open. It's not really open, but that's the only other real option, I call it open. It's not really open, but that's the only other real option from a consistent basis. You kind of need a government really to be there to sort of stitch it together.

But isn't that wild? Seriously, are some people now using CNNVD data in lieu of NVD data because NIST has done something weird? It's hard to say how much of that's actually happening. I think everybody is just sort of sitting around with baited breath and they're trying to find other ways. So like, for example, like obviously we have a partnership with Mandiant. And so Mandiant actually launched their own concept of a Mandiant vulnerability enumeration number. Man, it's a mouthful to say these things, but they have something called an NVE now. I mean, theirs is almost like, you know,

a vulnerability intelligence feed, right? Where they've got, you know, it's a bit richer, a bit deeper, sort of like Sysachev, but with more nuance and more bugs. Yep, and they've got, I mean, they, so their goal was to take NVD, add a bunch of vulnerabilities on top of it that they find within their own analysis.

And they actually score every single vulnerability that is in NBD. So they have the army of analysts that go and often do that too. But yeah, so they have something called an MBE ID and they try to correlate that to CVEs when they come out. But their whole goal is to try to be as early as possible. Because I think actually even another point,

we've talked about how threat intelligence is always kind of a lagging indicator for responses like vulnerability remediation. This is honestly why I find that people who spend a lot of time in incident response tend to design good products. Yes. Because they understand what, you know,

when they're going in there looking for certain things, you know, like maybe shifting that left gets you a good result. But yeah, it is definitely a, you know, like maybe shifting that left gets you a good result. But yeah, it is definitely a, you know, because it goes incident, incident response, threat intelligence. That's right. Yes, it does. Yeah.

Well, it's probably an order in there too, where it's like, tell all your friends, tell the press, then threat intelligence. Yeah, yeah, yeah. But I mean, are people actually using, are American firms actually using China's NVD now? I can't confirm that. I don't know for sure. But I think that we will resort to more and more drastic measures as time goes on. But as of right now, we don't have any confirmation of that, but I would not be surprised because there's a lot of, just quite frankly, there are a lot of organizations and companies in Europe that are trying to also stand

up their own vulnerability databases. And then there's some commercial vendors that are trying to stand up their own vulnerability databases. So we're starting to see like a resurgence of the conversation from 1995 all over again. So sometimes it feels like we're taking steps backward. Amazing. Now look, there's going to be a vulnerability management conference. That's right. First ever. A big powwow. Hell yeah. Called VulnCon. Oh, yeah.

Tell us about VulnCon. It's sexy just talking about it, just listening, just hearing the name. Aren't you guys all getting excited? I mean, you know it's going to be a wild time, right? Oh, yeah. I mean, 400 of your closest vulnerability management nerds, probably all of the nerds in the entire world that care about vulnerability management, are all going to be in the same spot at one time. Ain't no party like a vulnerable management party.

That's right. Yes. It's interesting, right? Because this is actually being put on by an organization called FIRST, which is another US kind of weird private public organization. And they are actually the ones that run the CNAs. And so every year, the CNAs all get together. And this year, they decided to also wrap a conference around it. So they're meeting, the CNAs are meeting all in one place in Raleigh, North Carolina. And then they have this conference around it. It's the first ever conference that is dedicated to entirely vulnerability management topics and concepts. And so some of it is like super, like really in the weeds, like, hey, what should we do with our CVSS version for, you know, base score, like with this little tiny proportion that we want to change, you know, from point one to point two. There's that, but there's also really cool stunt hacking type stuff, which is how do we do vulnerability management on automotive manufacturing?

So there's going to be some talks like that that are also really potentially interesting because it's very different than your traditional, you know, scan patch. Well, it's funny. It'll be like every other security conference where the talks are going to be about like really exotic stuff that basically has zero relevance to most people who are attending,

but it's fun, right? That's right. I'm not, I can't wait for the ATM. And then all of the relevant stuff happens in the hallway stream and, you know, everyone networking and actually sitting down and, you know, talking about their work. Now, look, moving on, Scott, to another development in the world of vulnerability management.

You know, it's funny, right? Because when we first started this call, you're like, there's actually a lot going on at the moment. And there really is. come in around regulations, requirements, I guess, procurement requirements, where these days, if you want to do FedGov work, you need to manage vulnerabilities according to some pretty strict federal government guidance. Is this for all federal contracts? Is it for contracts over a certain size or of a certain type? What more can you tell us about this? Yeah. And it depends how deep you want me to go down the federal government procurement? Yeah. And I, you know, it depends how deep you want me to go down the federal government procurement rabbit hole. I'm telling you,

I'm just a joy to talk to at parties, guys. But so yeah, so what happened is there's this thing called CMMC that came out a couple years ago. Actually, it was passed as federal regulation. Yeah, about, I think it was about two years ago. And the idea was that by a certain date, all new federal government contracts now have these new flow-down requirements. So that in order for you as a business to do any sort of kind of business or contracting with the U.S. government, you're now required to adhere to these CMMC controls. And a lot of those are cybersecurity information security controls. And a lot of those are cybersecurity information security controls. And one of those is very relevant to Nucleus, which is you have to now manage vulnerabilities and patch all vulnerabilities within a certain timeframe. And you have to track them in a very certain way. And it's an extremely onerous process. But the reason I bring it up is because I know,

I think last time I was here, we were talking about how this stuff was coming, right? The regulation hammer was on its way. Well, I think really the reason you're talking about it is because you make a product that is designed specifically to address this problem. Yes, may have come from the federal government and went to the commercial sector and then the federal government followed me.

So you're welcome, everybody. But yes, this is, I mean, the CMMC process internally to the federal government is very similar to something called the RMF process. And Nucleus was built originally to solve the RMF process inside of the DoD. So yeah, this is what we built the product for. So that was a shameless plug, but you know, we're here, I'm doing it. No, but I mean, look, there's going to be a lot of people out there going, oh my God, how do we even begin to get our hands around this and does this apply to all contractors of all size right because when i've had conversations with people at like

uh what's nasa's yeah like at the cyber security directorate at nasa and whatever and you talk to them about the defense industrial base and the makeup of the defense industrial base and we all think about the raytheons and the lockheed martins and whatever but there's all these little companies who might make like a very difficult to make carbon fiber component for some weapon or something. And it's like 20 people. You know, I mean, they've got their own requirements, right? Being dib. But I'm guessing that this is an issue in the federal government writ large, right? Which is that you're going to be dealing with some sort of medium size, you know, smaller and medium size organizations. Absolutely. You know, are they expected to do this as well? Yes, this applies to all kind of federal contracts going forward, right? At some

point. So are you starting to get some of these smaller businesses coming in, I guess is the question. We are, but historically, we actually couldn't do business with them because we were not authorized to do business with the federal government because there's yet another, believe it or not, security controls requirement that we had to meet, which is called FedRAMP as a SaaS service in order to have the federal government actually upload vulnerability data, which, fun fact, critical data that could tell a lot of people a lot of things about your environment. But in order to actually have the federal government be allowed legally to load vulnerability data.

To give you their list of stuff that their contractors need to cover, you need to be FedRAMPed. That's crazy, but you are FedRAMPed now. We are now officially FedRAMPed as of the 29th of February. And our joke internally was that hopefully that means that we only have to get assessed every four years because that was an awful process. It took 26 months from start to end. No one has ever enjoyed the FedRAMP certification process.

Oh my gosh. But look, now you're FedRAMPed, you've got the data flowing in and whatever. I mean, I'm just curious to know if you're going to have to build some version of Nucleus that... Look, another reason you didn't do business with smaller orgs and I know because I got an email from someone who was very disappointed they couldn't buy your product because they just weren't big enough and I had to write to them

and say look you know they're a startup they only have so many people there's support overheads and things like that so they're targeting larger organizations just for now right yep that's just how it is with startups but you know as you're growing and you just took a series B for like 30 something million, right? I'm wondering if you're going to actually start now pushing this down and, you know, have different versions, I guess, or different presentation layers of your, you know, service for these smaller businesses now, because it sounds like they're going to need this as a matter of compliance. Yeah, definitely. Right. And a big part of the, especially on the federal side, the only way we could make that work is if we got FedRAMP because, you know, otherwise you'd

have to deploy on-prem and it just isn't worth it to deploy a big data aggregation system for, you know, 500 IP addresses. Right. But in the background in the last year, we've actually been hard at work building a ton of partnerships with service providers and MSSPs and MSPs and VARs and all that. And the idea is that we can actually work with partners who can – kind of like how it works with cloud providers, right? Like there's Presidios out there in the world, TubiCloud, et cetera, that will actually work with AWS or Google Cloud on your behalf. And they'll basically buy a bunch of cloud services, and then they'll actually distribute it to you, and you get it at a lower price. And then you also get to work with that reseller or partner to kind of manage the service for you. So we're establishing huge relationships like that with a whole bunch of different partners, just so that we can solve

this exact problem. And so one that we've had for a really long time in EMEA has actually been Orange Cyber Defense. So they've been great to work with. So they manage basically a whole swath of customers that normally would be probably too small. That used to be SensePost, right? Used to be SensePost. That's where Orange Cyber Defense came from. So they're good eggs, that lot. They are. They're good eggs, that lot. They are. They're good eggs. Charles, shout out to you, man. Charles van der Vult. Yes.

Good friend of mine. That's right. He took a chance on us a long, long time ago and wouldn't be here without him. So very much appreciate the Orange Cyber Defense and Sensepost folks. But yeah, so to answer your question, that's exactly something that we're working towards. My goal and my co-founder's goals was specifically to, originally, we actually wanted to go down market first. We wanted to say, we want to democratize vulnerability management to the point of what would it be like if you could completely automate away the job of a vulnerability analyst? So if you're a mid-sized organization who can't afford a specialist in VM, you don't have to do that. You can buy a subscription to a platform

and automate away that whole process and avoid that. But turns out if you automate away entire job roles, then that's very exciting to large, large enterprises. And so we got dragged up market really quickly. And when that happens, it's very overwhelming, especially when you grow really quickly like we did, where you just can't support multiple business models at the same time. And so we did have to specialize kind of upmarket. And so, you know, we have over 100 customers. Most of those are pretty far upmarket. And now as we're expanding, we are trying to do our best to bring the services down market. And I think doing that through MSSP partners,

or I guess we're calling them MDR. I mean, maybe some of the MDRs are now, well, are they doing MDR if they're doing this? Not really, because it's not detection and response. But yes, point being that some of these firms that do managed services in security are going to be the ones best positioned to deliver this to the SMEs.

And I think it makes sense what you're doing. Yeah, and they're going to get a better result, right? I mean, they're going to be the one's best position to deliver this to the SMEs. And I think it makes sense what you're doing. Yeah, and they're going to get a better result, right? I mean, they're going to have people that they can call 24-7 who are already oftentimes managing their SOCs for you, right? It's, hey, they're a SOC service, and now you can add vulnerability scanning and patching and management and reporting all in one, and you get to access the Nucleus platform through it as well.

But again, we wouldn't be there without all of our FedRAMP accreditation and all of that sort of stuff that we've been going through. So yeah, it's a pretty exciting time. I mean, obviously, we're very fortunate and thankful for the investors. I don't know if for those not familiar, it's kind of a tough time to raise money right now, especially if you don't have the words AI in the name. Not for risky business sponsors, buddy. Not for risky business sponsors. They're doing fine. And that's the thing. VCs aren't just

throwing money at people anymore. They're actually asking you if you have a plan with what to do with it instead of just like, take a hundred million. We're good. Yes. Especially if you don't use AI in the name, right? If we had Nucleus.ai, it'd be a different story, but, you know, we have to. Oh, well, congratulations on that. And, you know, I mean, geez, it was just you and a founder, wasn't it, when you joined up with Risky Biz?

It was, yeah, there were three founders and it was just the three of us when we got started. So three of you all the way through to Series B. My babby's all grown up. It's very exciting that's right man you're not going to recognize us soon we're going to hit a growth spurt and grow some acne all that sort of fun stuff that you uh that's right sniff wipe a tear from my eye all right scott kufa that's all we're going to have time for on the soapbox today uh a pleasure to chat to you

always good to see you my friend and uh you know all the best with the the new phase of nucleus to the moon mate to the moon yes later thank you so much see you, my friend. And, you know, all the best with the new phase of Nucleus. To the moon, mate. To the moon. Catch you later. Thank you so much. See you, Patrick. That was Scott Kufa of Nucleus Security there. Big thanks to him for that.

And you can find them at NucleusSec.com. So Nucleus and then SEC.com. And that is it for today's edition of The Soapbox. I do hope you enjoyed it i'll be back soon with some more risky business for you all but until then i've been patrick gray thanks for listening