Growing Government and Industry Adoption of Protective DNS with Infoblox

If you can't tell, we obviously love our tech. We love what we do, and we think it's super important and a fundamental way to protect, um, networks and customers. But you may be thinking, does everybody else think that, right?

Is it just Infoblox saying protective DNS is, does the rest of the industry think the protective DNS is important? And I'm here to tell you that, yes, there are many proof points here, um, in just in the last, I would say two to three years, where there's been a significant increase in adoption of protective DNS by government agencies and by private industry. So I am gonna give you four examples, right?

Um, on what those, um, what the adoption looks like from a government perspective and from an industry perspective. Uh, four things. First is I'll talk about, you know, what governments around the world have already implemented some sort of protective DNS, um, and what are they advising for the private sector?

Uh, what does NIST talk about when it comes to DNS? And this is, again, very fresh. Uh, they're gonna publish something very soon.

Actually, we heard they're gonna publish something by end of September. I'll talk about what, what it is. And then two other industry stalwarts, right?

Microsoft and Google. Uh, so we'll talk about how they are implementing protective DNS. You already saw Google DS or where you got a sneak preview from, uh, session.

I'll just go in a little bit more detail. Alright, so let's talk about government first. Um, if you remember, I think this was about three or four years ago, there was a statement from NSA that talked about how protective VNS is different from other security, uh, uh, related tools and why DNS is not just for protocol serving, but it's for use as a security service, right?

To block bad things, to block, um, you know, users from going to malicious domains to mitigate threats. Uh, leveraging DNS, right? This quote was from NSA, uh, about three to four years ago.

And we all know what is protective, DNS. Everything that we've talked about till now is protective. DNS preventing the initial infection, preventing users and devices from going to known malicious domains and high risk domains, stopping those C two communications, stopping data xFi, the data xFi also can happen over DNS.

And, uh, you know, NSA has, uh, come up with that. And you can find these documents on the website about using protective DNS and why it's important. And they also have, uh, material around what are the leading protective DNS vendors out there.

Let's talk about, um, other governments. So, uh, there, the, the quote from Ann Neuberger, she was a former director of cybersecurity at NSA. Based on the analysis that they have done, they found out that 92% of attacks use DNS at some point.

So if you use protective DNS, you have a good chance of blocking and stopping 92% of cyber attacks, right? Um, and are governments using it? Absolutely.

So if you look at the first column, us, um, so CISA provides protective DNS services for its federal agencies to protect federal networks, um, against cyber threats. So they actually are using DNS as a first line of defense to protect their federal networks. And if you see the stats here, you'll see how many queries have been analyzed so far.

20 million threats, malicious domains, so far blocked, right? And there are about 325 organizations and agencies using that service. They also highly recommend the private sector to adopt any of the commercially available protective DNS services from vendors like Infoblox and others to protect their enterprises.

So that's also an advice, uh, advisory from, uh, from the US government. Uk, UK provides protective DNS service to their public sector. It also includes emergency services.

So it could be like fire services, you know, 9 1 1 really, or equivalent services in the uk. And, uh, so all their public sector services are now protected using, uh, A-P-D-N-S type offering. You can see some stats there.

They've blocked, uh, actually a thousand, 1,400 organizations are consuming that service. 5 million, uh, malicious, uh, threats so far. And finally, Australia also offers protective DNS for their public sector and, uh, for the public agencies.

And again, you can see the threats blocked and how many organizations are consuming this service. So, um, so government agencies around the world are recognizing the importance of DNS as a first line of defense, as a first security control point. And these are just a few that have already deployed these services.

There are other agencies across, uh, sorry, there are other governments in the world, um, uh, that are in the process, right? And we have, um, you know, they work with us. We have Infoblox representatives working with those other government agencies around the world in Europe, in Middle East and a PJ.

Um, they, we are in discussions with them to figure out what's the best approach for, uh, for that country and, and that government. So, lots, uh, lots of activity on this. And I will say some, some governments are also thinking of having their internet service providers make this, uh, offering, uh, to protect private citizens, right?

So there are a couple of models there. Either they are required to purchase the government PDNS and offer it as a service to the private citizens as part of the internet service. Um, or, um, and, you know, they could charge obviously the individual citizens extra if they want to, but there are different models there.

Um, but again, the bottom line is it's, uh, this is, uh, a priority for, for a lot of governments around the world, uh, Ukraine. So let me talk about Ukraine. This, uh, they implemented protective DNSA couple of years ago, uh, just, you know, when kind of the conflict was kind of rising up.

And, uh, again, they, this was focused on protecting Ukrainian citizens against financial phishing and fraud, right? And so there were a lot of citizens were getting, you know, as, as Dave talked about, a lot of students were getting fooled into kind of giving up their personal credentials or giving up their bank account information. They were getting phished and they were getting robbed of their, their money.

And after deploying protective DNS, so there were about 3 20, 20 plus Ukrainian providers who have, uh, who are using this national PDNS service from Ukraine. And they saw a reduction of 30 to 40% in financial phishing fraud, um, that their citizens actually reported, right? Their citizens actually reported that they're seeing less and less financial phishing fraud after the service was deployed, um, for them.

So, you know, a significant impact there. And, um, as you can see, as a conflict goes on this, you know, these threats continue. And so they're using this as a way to mitigate some of that phishing attacks.

Um, so we talked about government agencies. So kind of let me, uh, you know, uh, pivot a little bit to regulatory bodies, right? We've all heard of nist.

Uh, they come up with guidelines for various security frameworks and technologies. And most recently, uh, they put out for public preview, uh, a, a special publication 800 dash 81 that focuses primarily on DNS, right? And, um, it's, the public comment period is over, and they're gonna publish the actual report, uh, by end of September.

Uh, that's what we are hearing. Um, but that special publication is focused only on DNS, and I thought this was a great quote that they had, which is they talk about DNS as a way to provide insight into connections and data flows, but also identifying security incidents earlier than other systems, right? So you saw some of the examples that, uh, you know, the presenters gave about how much earlier we are, 60 days, 50 days before other tools found malicious activity.

And they kind of, this, kind of put out the same, uh, uh, you know, information, right? So it's a foundational layer for cyber defense, and they actually cover three areas. The first one is protective, DNS, that is everything we talked about till now using DNS to block malicious activity, block C nnc block data, xFi, basically filtering DS queries and only allowing the legitimate DS queries to go out to the internet.

But they also added two more, uh, two more pillars to their recommendation. The second one is about encryption. So we've all heard about, um, spoofing, DNS spoofing, like mad in the middle type of attacks where, you know, a bad actor could look at where your DNS traffic is going.

They could capture it. They know what your activity looks like, and they can take advantage of it. So one of the things that came out about we, again, three to four years ago, was encryption, right?

DNS over H-T-T-P-S-D-N-S over TLS, where the actual DNS traffic is encrypted. So the bad actors can't spoof, uh, the DNS Ries and figure out what's going on. And so they put out that as a best practice as well, using encrypted DNS is a best practice.

Um, DNS sec, right? In ensuring you're assigning your DNS queries to make sure there's no kind of, um, hijacking and things like that that could happen, or cash poisoning that could happen. They put that out, uh, just proper maintaining proper DNS hygiene, right?

Separate your external or internal DNS, make sure you're there, no dangling CNAs or dangling records that you're not taken care of. All of that falls under DNS hygiene. And we are all, you know, everybody's very busy these days.

Even the DNS administrators are busy, right? Nobody, uh, really spends that much time to make sure the basic hygiene is taken care of. And what they're saying is, it's time well spent to make sure that your DNS is architected the right way.

So that's the middle part. The third part is all about protecting the DNS server itself. So you must have heard of DNS amplification attacks, uh, recursion floods, UDP floods, these are all targeted at ex generally an external facing DNS server, which hosts your website.

They, you know, bad actors want to crash your website, they'll send you a flood of traffic, right? And if the DNS server is not built to withstand that, um, it's gonna crash or it's gonna slow down. So your user is trying to go to your website, they'll not get to your website.

So what they recommend as part of the third pillar, is to make sure, you have to make sure whatever DNS servers you're using, or your external DNS can actually differentiate between flood traffic traffic and legitimate dus queries that are coming to your website, right? So if you don't respond to the flood traffic, if you know it's part of an amplification attack or, um, a reflection or whatever it is, then you don't waste the CPU cycles responding to those queries. You only respond to the legitimate dus queries.

Your D server is not gonna crash even if there is a DDoS attack on your D server. So that's the third part, right? Protecting it so that it stays up and running and doesn't, your, uh, availability doesn't go down during a DDoS attack.

So these are the three pillars that NIST came out with and pub and is going to publish, uh, pretty shortly. And if you, if you look at nist, why is NIST important? NIST is important because it's, it's a framework.

It's best practices. It's not a compliance mandate, but there are other compliance mandates. For example, NIS two in Europe, that's based out of nist.

So NIST kind of serves as, you know, um, or it feeds many compliance mandates around the world, NIS two, uh, critical security controls and a few others, right? So the fact that NIST is talking about it means this will make its way to some of those compliance mandates, which then makes it more urgent for especially companies that are bounded by those compliance mandates. Any questions so far?

So DNS security extensions, DNS SEC has always been just a complete pain to, to do. Um, maybe this is spoiler for your deck, is that something Infoblox can help with? Yes.

So we've, we hear this all the time, and Infoblox with our platform, we make it a lot easier to implement DNS sec, um, than if you're using some of the other other vendors. We don't have it in the deck, but we could definitely talk more about it when we have the open table session. But we do offer it, and we do make it easier for our users to implement DNS, but we hear that quite a Bit.

I know many organizations have failed at, Which is why that option is low, right? Exactly. Yeah.

Great question. Okay. Um, so moving on.

So I'm gonna now pivot a little bit. So I talked about government agencies, I talked about regulations and compliance. Now let's talk about zero Trust.

Zero trust came, uh, 15 years ago, right? It's still a topic of discussion today, because customers are still in that journey of really following the zero trust framework and implementing it to the best way that it makes sense for them, right? Zero trust is not one product click of something, and you bought a zero trust product, right?

It's a journey. And so, um, when you think about zero trust, right? People talk about network segmentation, people talk about identity, right?

Identity of users, identity of devices, giving access to devices and users, or giving only giving access to only those resources that that user or the device needs to access and blocking everything out, right? So when you think about the standard zero trust principles, you know, you always assume there's gonna be a breach. How can you contain the breach as early as possible to a limited part of the network as possible so that you can take action?

We all know the never trust, always verify, use the least privilege approach, constant monitoring and segmentation. But what most people don't realize is that DNS has a role to play in zero trust, right? I just pointed out a couple of things here.

When you talk about never trust, always verify. So if you are d, if you're just letting a DNS server go to whatever destination the user or device wants, you're implicitly trusting DNS, right? So you're not really doing zero trust if you're implicitly trusting your DNS resolver, right?

That's number one. Um, you need to make sure that it's not going to a malicious domain or a high risk domain, right? So DNS has a role to play there.

Constant monitoring. If you're not monitoring your DNS queries that are going out to the internet to check for, you know, is it exfiltrating data? Uh, is it doing DGA activity?

Is it going to zero day domains? If you're not constantly monitoring DNS traffic, then you're not really fulfilling that fourth bullet, uh, for zero trust, right? So our point of view is, like I said before, you're not really doing zero trust if you are implicitly trusting your DNS resolver.

And so what are the basic things you need from A DNS perspective for zero trust, first one, no surprise, right? Protective DNS, everything we talked about till now, make sure your recursive DNS resolver is acting on really d threat intelligence that differentiated, that's DNS focused that can block that malicious query to those domains using what's called the response policy zone. Response Policy zone is a technical term that's used, uh, by dn.

Uh, it's what the DNS OL Dissolver use to block that resolution, right? It prevents initial infection. C two data expo, the middle part, we talked about encryption, because encryption is also part of zero trust, and you need to make sure that your DNS server support dot, and do and, uh, other types of encryption for your DNS queries, right?

The third thing, which we haven't really talked about much till now, but it's equally important, is knowing what assets are on your network, right? That's not just, you know, my laptop, but it includes printers, it includes, uh, you know, any iot OT devices. It includes cloud workloads, right?

VPCs, uh, it includes your home users and their devices. So you need to know where user's connecting from, what type of device he's using to really make informed decisions about access, right? What do you want that user and device to access when he's at home versus when he's in the office?

What do you want your printer to access? Do you want your printer to go to any internet destination that it wants to resolve to? No.

Right? We just wanna restrict the external access for your printers. But to do that, you need to know that it's a printer, then you can set policies appropriate for that device, right?

So getting that UpToDate asset data across your entire hybrid multi-cloud environment is important. And that's where the related technologies that is to DNS, which is DHCP and IP at risk management, comes into the picture, right? Um, somebody asked, what are, I think it was probably you, you asked about, you know, why should you do protective DNS on a DDI platform?

One of the answers is, if you're doing it on a DDI platform, your IP address management has that asset information that can feed your protective DNS and it'll tell you which asset is going to that malicious domain. You have that asset inventory information integrated into the platform, and now you can make access decisions easily, right? And the policy can be applied based on asset type, right?

So together, this will help make the zero trust, uh, approach stronger and more, uh, uh, uh, more granular, I would say, right? Based on the asset type and where it's from. So proof point for that is Microsoft Zero Trust, DNS, Microsoft Zans came out with this public preview in April of this year.

This is all, and I think Anant alluded to this earlier, this is all about locking down. This is just for Windows 11 machines, right? So Microsoft is one of the first vendors who's embracing kind of this PDNS approach for zero trust.

And what they're doing is, uh, from Windows 11 onwards, they, what they're proposing is to lock down Windows 11 machines. And any DNS query that comes out from those machines will only, uh, or only the PDNS approved domains will be accessible from those Windows 11 machines. Any other domains, the domain resolution has to come from an approved PDNS resolver, right?

And this also answers your other question about hardcoded ips. It doesn't allow any hardcoded ips, uh, to get resolved, except for a few exceptions for things that need to work. There are some corner cases where there exceptions, but in general, if an attacker is using hardcoded ips, this will not work from Windows Alert machines.

They will not because it blocks any hardcore ips. Only those that the PDNS approves, only those domains will be resolved, right? So that's kind of, and we've, we've presented this joint solution with Microsoft in a few, uh, uh, you know, events and webinars including RSA Black hat and some webinars.

And, um, we are gonna do more with Microsoft, but I think this is one of those vendors that has really embraced that zero trust, um, approach for DNS any question. And they also support the, uh, obviously they also, uh, you know, want only use PNS Resolvers that support encryption. So the dot and toe piece that we talked about, DNS over htt, PS and TLS makes sense, is it?

Right? Um, okay, so we talked about government agencies, NIST and others. We talked about zero trust.

Finally, I'm gonna talk about the cloud workload. So this is basically a double click on what, um, ESH presented earlier. Um, we all know that cloud, you know, cloud workloads are also targeted just as much as individual user devices, right?

Uh, we get phishing in cloud workloads. You know, there are directly, there are a lot of applications that are very dynamic. They go out to the internet, they go out to malicious websites all the time.

And there are many other technologies to protect cloud workloads, CNA, and, you know, posture management, et cetera. But, um, one of the things that we kind go back to is a lot of those tools, again, are only as good as their threat intelligence. And a lot of the threat intelligence is reactive.

Whereas, you know, for, for all the reasons you heard till now, DNS based threat detection is a lot more proactive, is a lot more preemptive because we can identify threat actors before they are, uh, you know, before they weaponize the domain. So even if the cloud workloads are going to a high risk domain, it may be allowed by other tools, but we we'll block it. Uh, DNS can block it because we know it's high risk, uh, even though it's not been weaponized just yet.

So, and threat actors constantly, uh, you know, use DNS as a way to get around security, uh, other security tools. Uh, the other thing we talked about is native protection, right? Protecting cloud workloads natively makes it easier for customers and users if they're already using Google Cloud, they want, they, you know, generally they try to get security from Google Cloud or any other, uh, partner integrated security in the Google Cloud environment versus trying to put one more separate solution in the, in a Google Cloud workload.

So that's what we did with DNS Armor. We've integrated the Infoblox thread detection into Google Cloud, and so users get native protection when there are in the Google Cloud Con, and they manage it using the Google Cloud console. They don't need to go to different ui, they don't need to go to the Infoblox ui.

They get the, they get the threat detection of Infoblox without having to leave their Google Cloud console. And the way it works is, you know, let's say you've got cloud workloads. They're going to the internet using DNS queries.

The Google Cloud will serve the DNS queries, but they will also send us the DNS queries on the site as logs, and we run it into our threat detection engine to identify the same stuff that we've been talking about TDS, uh, high risk domains, uh, data exfil, DGAs zero A DNS, whatever threat it is, we run it through a threat defense engine, and we will send back information as logs about the threats that we've identified that can then be sent into, let's say a Google SecOps sim, right? And then the Google SecOps, the analyst can then, you know, and, and analyze what we've identified and then decide to block it further. I have a question.

Yes. Is it turned on by default, or is it the intention to turn it on by default eventually? Um, and is it monitored through Google Command Center?

I can't remember if that's the branding for it right now. Okay. So the question, is it turned on by default, or is it monitored by Google?

It's not turned on by default. So, um, customers have to turn it on, but they can turn it on at their account level. So once they turn it on at the account level or a project level, then all workloads that come up in that count or in that project, they automatically can to protect, but they have to turn it on first time.

And just to be clear, you're not handling the queries, you're just handling sort of enriching, Um, we are handling the queries, but the queries are responded to by the Google DNS. Okay. We get a copy of that query, and then we are running a threat detection on that.

And, and then we report the threats to Google Security Center. Um, this is version one where we are not in line. We are getting a copy, so we can do detection, uh, in next version.

We would try to be in line so we can actually block it. Um, but that's future. What about the analytic side of it?

The stuff that, you know, you get inside of the portal for on-prem. Do you see that information if you are a customer, like if you have an on-prem device, you're not gonna see that? No.

Is there any plan to integrate that? So you can, you can, um, you can get that same type of visibility for hosts that might be having issues or, you know, the, the reporting, the executive reporting, all the other things you can get out of your, your portal? Yes.

Future. Future, Yeah. We'll, Yeah.

Okay. Awesome. Um, and, and the good thing about this is, um, they get the same threat detection that our standard threat defense customers get, right?

Um, and so if a customer wants to extend this DN let's say they start with Google, DNS Armor, and they wanna extend that protection to other clouds that they're using or to their on-premises environments, they can do that with threat defense, our threat defense product. So they get kind of the similar threat coverage, I would say for the Google Cloud. Or let's say they're using AWS or they're using Oracle, whatever it is, or they're using on-prem, they get the same threat coverage.

Oh, so we were talking in the, the round table about policy enforcement points, detection points, information points. One of the ideas with Zero Trust is I'm authenticating, I'm authorizing, I'm accessing, and the decision to allow that based on the context and conditions that request. So I like that your, your coverage of DNS as a component within Zero trust.

Um, is there any access API or otherwise into other tools that would be able to enact as zero trust action? So for example, my IDP logs, everyone off, uh, single signs off, uh, all sessions for someone when they notice their endpoint is beaconing out, or, um, you know, a a host gets isolated at the network level when we notice a bunch of malicious traffic at Infobox. So You're thinking if a device is compromised, do we have the ability to say no DNS responses to this whites, like black hole it Well black hole, but also like expose that as, as a signal either through shared signals, uh, protocol or something else that other tools could use?

Yeah, I, I can definitely answer that. I hope the mic's working in. So we actually have something called our ecosystem.

And so, uh, and we connect it with our insights or with the actual DNS queries. When it's malicious, you can connect it. There's a lot of ways we can do it, but the idea is, hey, when we detect these assets and we know about them, we can send that information to a NAC or to a firewall automatically and shut them out of your network or put 'em on a new policy to, and typically that's how customers like to do it, is they like to put them onto a new policy.

Yeah. Until they know for sure, okay, this is malicious. And then they do some sort of, uh, vulnerability scanner, which we can also automate with.

So like 10 all rapid seven qualities, those can then be triggered later on to say, Hey, go ahead and scan these assets that violated this policy. Typically set that up with the, the actual insights themselves. 'cause those won't trigger a million times in a second.

Right. But you can't, and we do have it set up so you can say, Hey, if it's over this threshold mm-hmm. Of we have our own threshold to 8,800, if it's over this number, go ahead and scan this guy or go ahead and put 'em on a new policy.

And that could be for a firewall or an even a nac, right? So we, we have those Mac Mac addresses too. Good.

All right. Love that. Thank you.

We have a, a whole ecosystem kind of portal on our website. We, we support like 30, 40 different ecosystem lenders. 'cause we know customers like Choice, right?

They have a lot of tools on their network. We kind of integrate with a lot of the leading vendors and across all security categories for various use cases. Seems like you have a, a very automated system, which I love, uh, on a daily basis.

What's the typical user interaction with not, sorry, typical security user interaction with the product? Actually, um, and you guys can answer as well. What I hear is it's a lot of, you know, set it and forget it.

We are doing, you know, all the blocking. Um, we don't have any false positives. Uh, so not a whole lot of daily interaction.

We are just silently protecting and reducing the traffic on, on their network. Um, when there are incidents, they need to come in and check things out. They do.

We have a lot of reporting built in, but a lot of those, uh, queries are also sent to their same tools. So the SOC teams can look at them. The SOC insights thing that Kevin was showing, uh, we can also send that to Splunk.

Uh, so instead of looking at thousands of queries, they can look at just 17 insights. We have a Splunk app that also gets fed by it. So it's a lot of interaction happens that way.

Um, not enough customers logging every day to our tool and even dossier that he was showing you mm-hmm. Is all exposed via APIs. So customers have integrated that in their tooling.

So they can just pull information from dossier using APIs. And then from a, how many queries do we look at every day? We, we analyze about 70 billion DNS events a day.

That includes customer traffic, it includes PDNS data. So just to give you an idea of the volume that we are looking at every day, One thing you didn't really touch on was the client agent might talk on that because that helps protect the device corporate devices when they're off the corporate network. Mm-hmm.

Yeah. So the endpoints themselves, uh, like you're saying, can be deployed. Uh, and so if they're mobile and they're going all over the world, you, I'm on a plane right now.

I'm flying over here, my laptop that's right here, still protected Infobox, knows about my IT team, if they need to, can set new policies instantly, it's automatically protected, right? So no matter where I go with that agent, now I am protected. And of course, there's other ways to set that up too, right?

We talked about NAS X as a service, you can deploy other types of endpoints and use us as the DNS resolver, right? Through them. It's just how you slice and dice it.

Different customers like different things. If you're good with endpoints and you like to use your UDM to deploy them, a lot of customers are good with that and like it awesome. Here's an endpoint.

It's easy. Deploy it. You're off to the races, you're like, Hey, I don't need another endpoint.

We have options for that. Absolutely. And sometimes our customers tell us we don't, uh, we don't, you know, can you work with an endpoint agent we already have, right?

So, uh, we do, we can work with like, let's say Zscaler sasi agent, right? So we have customers where they use, uh, Zscaler to do its thing first, and then we can, the Zscaler will route the DNS traffic to info blocks. So we do our side detection and then the queries go out.

So we can, we have integration architectures with other vendors Saw a dotted orange line. What do you do with them? Yep.

So, um, as part of our universal DNS management vision, um, we started with AWS Route 53, Azure, D-N-S-G-C-P-D-N-S. We managed those, you know, from our portal. Um, and in about one and a half months we are gonna start managing Microsoft, CloudFlare, Akamai, DNS as well.

So again, it's part of the universal DNS management vision. Uh, our customers are looking to manage all DNS systems from a single management portal, which is Infoblox portal. So yeah, we are gonna add those to, to our, uh, management.

Yeah. Back to the endpoint agent. Does, does it run on its own or does it actually require your either on premises or cloud services?

It can run on its own. Uh, we do, it does work better if you have it connected to the internet. So it does for the track it's up.

If by any reason that gets disconnected, there is an offline mode that will actually kick on. It doesn't pull all those feeds. That's a massive amount, right?

It, it picks the subset of like really important feed. Like, Hey, if you go here, it's, it's really, really bad. And that's the one it pulls down, keeps you protected to a certain level, right?

Because if you pull down, like we said, 17 million onto a single Windows or iPhone, it's, it's another, you're gonna destroy your own machine on accident, But it at least detects, so you get the walled gardens on United Airlines and hotel and things like that. It'll detect if it can't too late now. Be loud enough.

Oh, we have tight noise gates. So, uh, well, I'll ask another question, which is clearly, you know, in the intro you set it up, you talked about the, the scale of stuff, right? You have the F 100, F 500 lot of different verticals that you're involved in.

Um, can you talk a little bit about sort of how the solution plays in the S-M-B-S-M-E space? Smaller, smaller organizations and or MSPs? For MSBs, We don't have a lot of SMB.

Okay. You know, customers, uh, our, even our commercial segment starts with like 2,500 employee size. Mm-hmm.

So we haven't gone into the SMB space. Gotcha. Um, MSS PS something we are, are starting on.

Uh, so maybe that's one way to get to those SB customers, but, you know, we are 2,400 people, you know, going to SMB would require a totally different approach and we haven't done that yet. Gotcha. Thank you.

Just to add to that too, a lot of those m SSPs and stuff use our NIOS appliance as well and they pull those fees and they, they use nios mostly and they host it themselves. So yeah, a lot, a lot of our services come or their services, you won't know it come through them. So maybe we are serving a lot of those SMBs, but we just don't know it.

Yeah, and that's a good point. 'cause SMBs are getting attacked at record numbers. So we're hoping the MSSP play really can kind of cover those.

You know, it's not gonna cover the, you know, five, 10 person shops, but at least the sub two 50 companies we're hoping they'll cover.