Security Maturity Plateaus: The Tool Sprawl Trap

Shahin Pirooz: Here we go, April.

Brian Moody: So we've talked about this for years and years now. We've talked about tool sprawl and the trap that it becomes. I mean, this has been the foundation of most partner, most customer, security offerings has been let's add another tool, right? We've got 10 tools. Oh, hey, we've got to cover another vector or, you know, oh, hey, we've got AI now, right? We need to bring some machine learning in, next tool. And ultimately kind of today we're talking about the security maturity plateau is at what point do you hit a point of inefficiency.

Shahin Pirooz: Yeah, it's like you said, you start out with everybody— endpoint is easy. The market is focused on endpoint. So you start out with an endpoint security tool, then you quickly realize that really doesn't do anything for email. So then you go with an email security tool and you quickly realize nobody's protecting DNS. You add a DNS, and it just keeps—the dominoes just keep falling.  

‍

And the implication is you're going to at some point find yourself at a point where you've got more consoles than you have people and you don't have enough time to go look at those. And what we're seeing is on average it's about 20 technologies to make a proper security stack, and it's at about 10 to 15 that it starts to become a problem. So at 10 to 15, you're not fully secure in your stack, but it's already becoming a problem in terms of managing it, operating it and, more importantly, integrating it. And the reason integration is key is without that integration, you've got 15 silos that you have to figure out how to individually manage and operate.

Brian Moody: Oh, it's death by a thousand consults, right?

Shahin Pirooz: Yeah.

Brian Moody: So I would say for those of you who join us today, customers, partners, think about your current stack that you have now. Think about the technology debt associated with it. How many tools do you have deployed? How many staff members do you have that are monitoring the telemetry from these? How are you monitoring that, right? Are you flipping between consoles?  

‍

And this is one of the things, again, like I said, that we've talked about is how are you normalizing and/or correlating that data across all those consoles? It's a huge challenge and really it creates gaps. And it creates vulnerabilities. And, matter of fact, at the bottom of kind of our kind of advertisement for this talk is hackers need one gap, just one.

Shahin Pirooz: Don't give it to them.

Brian Moody: Don't give it to them. Well, we try not to give it to them.

Shahin Pirooz: Well, the reality is it's funny, the conversation that forced us to be a few minutes late, we were having a dialogue with some folks and we basically said, look, we have, for the last 8 years, maintained a dwell time detection of 6 minutes or less. Obviously, the shock and awe was there and it's like, "How can you say that?"  

We have facts to prove that for the last 8 years, we're able to detect bad actor activity within a network within 6 minutes of them landing, which is huge. The industry average is 200 days, so we take it from 6 months to 6 minutes. The only way to accomplish that is what we just talked about.  

‍

The other thing Brian said in that dialogue was that we assume they're going to get in. We just need to be able to identify them quickly and stop them from causing trouble. Because they are going to get in. There's no way to plug every gap. It's just like the Little Dutch Boy. You're going to keep sticking fingers in the dam, but there will be more cracks. There will be new cracks. Every new application generates a crack. Every new solution you put in place, every upgrade you do, every patch you do, there's something new that comes up. So you can't possibly stay ahead of it all. There will always be a gap. You just have to be able to respond when somebody takes advantage of those.

Brian Moody: And how quickly can you respond to that?

Shahin Pirooz: Exactly.

Brian Moody: So let's dig into that a little bit from a standpoint of, you know, you've got all these tools. How important is the correlation and the normalization of that data?

Shahin Pirooz: It's critical because the way you get to 6 minutes of dwell time, or a mean time to detection, is you have to be able to understand the flow of a thing happening.  

So for example, somebody clicks on a link in an email. The first thing is that there's a phishing, potentially a phishing alert or a suspicious email alert. It might not call it phishing. The next thing is there's a DNS alert that they went to a known bad site. The next thing is there's an identity alert that their identity, there was an account takeover attempt. The next thing is there is a malware alert that there is some malware on that user's endpoint. The next thing is there is a lateral movement alert that that machine is now trying to do things that it shouldn't be doing across the network that is tied to behavior.  

‍

So, without being able to trace that path from that first click to that lateral movement and understand how this attack came in, you don't have security. You have point solutions. So the only way to build a proper integrated stack is with being able to correlate the information from all of that. And the wonderful thing about AI is it helps us be better and faster at everything we do. The negative thing with AI is it's an arms race and everybody's building their own.  

‍

And everybody says theirs is best, but it's siloed. It's their AI, in their tool, on their telemetry, and nothing else. So if you've got an AI in your EDR and an AI in your email and an AI in your DNS and an AI on your network, they don't talk to each other. They're not interacting. The only way to do what we're talking about is correlate the information across all those tools and run the AI there. And that's what we do.

Brian Moody: And that's what we do. So that's such a great point, is that those AIs are running in the silos. Your tool is a silo. So think about this. I mean, it's almost as if you're having a conversation and, to your point, you're having 10 people talk to you at the same time.  

‍

There's no possible way for you as an engineer or one of your tech folks that is managing this infrastructure for you. There's no way for them to take that data in and be able to make sense of it.

Shahin Pirooz: Now let's exasperate that. This is like 10 of your drunk uncles talking to you, because when you're talking to AI, you're like, wait, are you sure? Did you mean to say that? And if you're doing that with 10 different tools, you're quickly going to waste every benefit that those tools gave you.

Brian Moody: Everybody has a drunk uncle.

Shahin Pirooz: But not everybody has 10 drunk uncles, right? So one drunk uncle you can handle. And so the joke around that is like, if you have a centralized core platform that is doing that work and the integration and the analysts are able to interact with it in such a way that they can talk to one drunk uncle instead of 10, that's a huge step upwards and being able to normalize data quickly.

Brian Moody: Well, we talk about technology debt all the time, so let's talk about that from a standpoint of if you think about the 10 different consoles, 15, 20 different consoles you have and the technology is that we also talk about this constant state of patching, constant state of updating, you know, these tools tend to be in some sort of flux regardless, right? Have you updated all the new hashes or the new algorithms into them? Because it's constantly every day, you know, these databases grow. Have you tuned your tool?  

And, again, gaps. I mean, if you haven't refreshed that particular tool, if you haven't updated the threat feed or you haven't updated the algorithm, you miss. And you only have to miss one time. And that's the hard part about this war.

Shahin Pirooz: It's continuous—

Brian Moody: Ongoing.

Shahin Pirooz: Yeah, continuous fine-tuning.  

We had a partner who was using the same EDR technology we do. And as soon as we migrated their endpoints onto our platform, alerts started popping and they said, How are you guys getting alerts and we didn't get alerts? Well, we're like, we added new correlation rules, we added new threat vectors. Our threat intelligence is our threat intelligence, not just relying on the EDR manufacturer. Have you done anything to fine-tune your platform? No, the vendor does that. No, the vendor does not do that. The vendors do not do much more than clean up and triage the information in the platform.  

‍

So it's important to understand that the problem with tool sprawl is tools. You keep adding tools and you keep purchasing tools, and guess what? In 3 years, you're going to have to find and replace a solution for each of those tools. And now you have to make the investment in time, resources, evaluations, look at 5 or 6 vendors. That continuous cycle never ends, and that's one of the burdens that our evergreen stack takes off of partners.  

‍

But that's not the only answer. We launched our Open XDR last year specifically for partners who feel like they have that part of it nailed. They've got a process around it and they're happy with what they do. Open XDR brings our threat intelligence, threat hunting, and attack surface management and layers it on top of that partner's ecosystem. Or even if partners have different ecosystems for each customer, same thing, run Open XDR over their ecosystems.

Brian Moody: So you just stole the path that I was going to go down.

Shahin Pirooz: I'm very good at that.

Brian Moody: Well, you have these tools, and you have your engineers, and even if within your organization, if you do have 4 engineers or a manager or you're trying to run some form of 7x24 vigilance, talk deeper about how important security operations is.

Shahin Pirooz: It's critical because even if you bring—like when we're talking about the drunk uncle conversation—you have to have somebody who can call BS on the drunk uncle and say, no, that doesn't sound right. I know you looked at all this data and you came back and said there's definitely a threat happening here, but can you show me why and where does it come—what are the vectors? What are the IP addresses? Where did you get the information?  

‍

You have to be able to have individuals who can have that dialogue. And, they need to be available 24/7 because bad actors don't work during business hours. The bad actor's entire life is all about defense evasion. So detection evasion. The only way to do that is several-fold: create really, really smart tools that can bypass or disable security controls, or do stuff when people aren't watching. That's it. So if you don't have 24/7 security operations and they're not technically savvy individuals, that's when the bad actors will be able to take take advantage.  

‍

And a significant part of the reason that we're able to do 6-minute dwell times or better is because we have 24/7 senior security engineers sitting on the consoles and leveraging our technology, integrations, and our normalization of data across all the tools. And they have easy access, one-click access to any console they want to look at, so that they can jump between consoles and get deeper information and do their own investigations beyond what the alerts tell them.

Brian Moody: Well, I think the other aspect of that is is having some form of event and incident management behind that. So the WhiteDog management interface, I think, is critical as we correlate, right? We bring all that telemetry in and that normalization and correlization—correlization, is that even a word?

Shahin Pirooz: Correlation—correlization,

Brian Moody: Correlization. Say that 3 times real fast. But I mean, from a standpoint of taking all that data and putting it into, in a sense, one pot. And as you stated, then running the AI, running the machine learning across that particular pool is what creates kind of unique discoveries, vulnerabilities, and I would say that the anomalies that we detect. And I think that's what's so important.  

‍

We've said all the time, set all these tools up but don't put security operations behind it, you might as well put a guard tower up and not put a guard in it. You'll hear that kind of tone out of us all the time. The other aspect you hear out of us all the time is hackers no longer break into your environment, they log into your environment. Identity is so important, and the issue with that is, is that your tools are not going to see a valid login. And this is where kind of the aspect of our attack surface management.  

‍

But, you talked a little bit about behavior. You've heard us many times tout zero trust. There's no one tool that gives you zero trust. Zero trust is much more of an ideology. It's much more of a plan. It's much more of a platform that you integrate across multiple tools that provides you with a zero trust environment.  

‍

So talk about that. We kind of put in our notes you know, the CISA Zero Trust infrastructure that's guiding you. Talk a little bit more about that and how that impacts this maturity plateau.

Shahin Pirooz: Yeah, I'm going to grab my notes here because I listed out their pillars in their maturity roadmap, basically. So CISA Zero Trust version 2.0 is really designed around 5 pillars: identity, device, network, application, and that includes email, and data. And data is really DLP.  

‍

And so what CISA is saying is everybody should be looking at zero trust as a way to look at their network, look at the security of their environment. And we've had multiple of these conversations where zero trust is a dirty word to most people, but it really is not a new topic. It really is something that's been around for 30-some-odd years. It's literally, if you ignore the words, like take the marketing out of the conversation for a second, all it means is move from an implicit trust to an explicit trust model. Rather than implicitly trusting something or someone because they're in your location, move to an explicit trust model where you say, who are you? And validate what access they have. And is this machine a machine that I've configured? Does it have the tools that I've put on it? Does it meet the requirements to connect to my network? Is the data this individual is accessing something they should be accessing? And is it something that they should be allowed to send outside of our company? That's it. That's zero trust. It's not complicated.  

‍

There are simple ways to solve this problem. We feel that our offering models tightly with the CISA 2.0 model. But, for those of you that are listening who are on the fence, don't—if it doesn't feel right. But go do CISA zero trust 2.0 without us. We can solve that problem for you very quickly overnight. We've got in all 5 of those pillars, in identity, we've got our zero trust identity portfolio, which is doing identity security posture management. It is doing identity detection and response, and it is doing honeypotting that Brian talked about earlier.  

‍

In the device space, we've got zero trust network access components, which do device control to identify the trust level of that device. Does it meet the configuration requirements you have for it to connect to your network remotely? To connect to your applications remotely?  We've got endpoint security solutions. We've got DNS security solutions that tie into the device and the network.  

‍

So the network layer is the next thing. We're doing packet captures and flow analysis on your network to be able to then feed that data into behavioral and intrusion detection systems to see what is going on on your network so that we can tie the click from the email to the behavior on the network that's happening.  

‍

In the application email space, we're going beyond the traditional gateway-based email security, which is, if you look at traditional email security, it's like antivirus back in the '80s compared to EDR today. We're doing the EDR of email security, and gateway security solutions are like the old antivirus solutions in comparison to capability.  

‍

And so beyond that, we've added a full portfolio of services we're coming to market with in our application security posture management, in our messaging or collaboration security posture management. DNS security posture management that ties in with that.  

‍

Then finally, in the data space, we don't—Brian hinted at it, or not hinted, he specifically said we don't believe in DLP. DLP is broken. The notion of being able to tag your data and create a taxonomy that says what people are allowed to ship around and send out or look at or whatever is tied to tags that you put on documents. Who's got time to go and put all the tags on the documents? That's a lot of work. And as soon as you do it, it changes and now somebody has to go back and do it again.  

‍

And so our approach is much, much simpler. We have a data security posture management that shows you your risk based on regulatory or compliance-based analysis of your data across your endpoints, your OneDrives, your SharePoint, your Teams, your Google Drives, so that you have a view of what's out there and what the risk is. And then at a push of a button, we can encrypt that data so that even if the bad actor takes it, they can't do anything with it. It's useless to them.  

‍

Let's take the approach of protecting the data, so data loss prevention, not data leak prevention, is what we really focus on in our DLP offerings or our data risk management offerings. That rounds out those 5 pillars. If you think about those 5 pillars, that's 5 technologies to add to your stack. At least.

Brian Moody: Well, one of the key things that, again, I keep coming back to is what we do at WhiteDog. We implement these tools. So we have the stack and, as you mentioned, it's close to 60 tools that we've implemented across our stack of applications and open source and things that we've developed to create the platform. And so that's one of the things I'd like you to talk a little bit more about is, as we talk about the tool sprawl, what you'll see more and more, you see it out of Cisco, you see it at Palo Alto, Kaseya has been buying, buying, buying, everyone is trying to create these platforms, right?  

‍

Talk a little bit more about WhiteDog, your vision from before. You started building a platform almost 10 years ago. I mean, you were so far out in front of this and where we are today and why it makes why it makes WhiteDog unique.

Shahin Pirooz: So as we think about tool sprawl, which is, you know, everybody cringes a little bit when you hear that. It's I don't want a 20-tool security stack that I have to constantly refresh. The problem is you have to have it. There isn't an answer today. There is no one vendor or one manufacturer that can cover the breadth of what you need to do this well. There's a lot that claim they can.

Brian Moody: They'll tell you that you only need them.

Shahin Pirooz: They do. And so what feels like the answer is going to an all-in-one vendor, and they'll solve everything for you. And Brian mentioned some of the logos that have that answer for you, meaning they say they have that answer for you. The reality is you need at least, in a proper security stack of a 1,000-person company, it's 30 technologies, not 20. So anything below that is 20, and then anything above that, it's 30 and can get even more complicated depending on what you're trying to do.  

‍

So if you think about the 5 layers of security that we just talked about, ours is a little bit slightly different than CISA, so I'm going to use ours. But email, DNS, identity, endpoint, and network. Those are the 5 layers. Those are the attack surfaces. There's more attack surfaces, but those are the keys. Those align pretty closely to what CISA is now calling their Zero Trust version 2.0 model.  

‍

If you think about that, there's probably 3 technologies in each, and that's where your 15 tools come from. So then you start to expand to do a little bit more outside of each one to figure out how to plug things together, and that's how the tool sprawl starts to happen. What's challenging when you have that is now the integration we talked about before.  

‍

The reason we built WhiteDog the way we did was we knew you're not going to find a single manufacturer. We knew we wanted to take a best-in-class approach to the tools we were going to use. If we were going to put our name and our brand behind our services and we were going to invest in technology to make that happen, we wanted to make sure that that technology is going to hold up our reputation. So we always pick best-in-class tools.  

‍

Do they stay best-in-class? No. We've changed almost every category of tool in our stack over the past 8 years. And that was the second construct in the way we designed the stack was it has to be composable. We need to be able to take out an engine and replace it with another engine. Very modular approach to doing it.  

‍

Then we had to create a way to be able to normalize the data across all of these tools. If you're looking at 20—60 consoles in our case—there is no way a team of any size can be effective. So in order to be effective, you have to figure out how to consolidate into what is core, what is important, what are the alerts, and then use some of those consoles to jump to to dig deeper. So the evolution of WhiteDog, and people say you're doing what we do, probably not wrong. You're probably not as mature as we are.  

‍

Because I can tell you, in past lives I've helped Fortune 50, Fortune 100 companies build out what I'm talking about. And we are far more mature than some of those companies. For the size of company we are, we are significantly matured. It took us 8 years to get here. If you've got a ton of money and a ton of time, you will catch up. We'll be far ahead from where we are today, but you'll catch up to where we are today. All I'm saying is, if you're trying to build this stack today, you're going to fall behind all your competitors because they're not. They're not taking the time, money, and investment, and some of them have tried and then shifted and said, we're going to partner with the likes of WhiteDog or all the other logos.  

‍

And our simple philosophy is you can't put all of your eggs in one basket. And while we look like one basket, we're not because we spread our risk across commercial technologies. In that 60-technology stack, there are 50 of those tools, 45 of them are commercial best-in-class technologies that we build OEM relationships with. The 10 of them are open source because we could not find commercial tools that would close the gaps we were trying to solve. 5 of them are written by us because we could not find any tools, commercial or open source, to solve the problem and we wrote our own.  

‍

So that ecosystem is designed as an integrated platform, unified security platform, that enables our partners to accelerate their security maturity from wherever they are to a mature security solution platform company, MSSP, and take that to market as their own service, white-labeled, co-labeled, or resell, whatever fits your business model.  

‍

To come back to your question, you cannot have a security platform that is one vendor. That's not a platform. It doesn't make sense. That's basically somebody put a portal in front of their own technologies. You cannot have acquisition-based growth in a single vendor because the acquisition-based growth makes it look like it's unified and singular, but in fact, all of the tools are not integrated together on the backend. Some may have data lakes, but those data lakes aren't really fine-tuned to the level we're talking about. The AIs are still in each stack. They're not on the backend.  

‍

So there's so many things that you have to take into account when you're looking at there's an easy answer out there. There really isn't. I would argue we could be very close to an easy answer, but it's because we're doing all the hard work on the backend. These OEMs and manufacturers are not doing the hard work. They're acquiring companies to take out competition or enhance their ecosystem.  

‍

But they now have earned additional technical debt in each of these categories. If the engine they bought is no longer effective, they can't throw it away. They have to fix it. We can throw it away and modularly replace it with the next best thing.  

‍

The bad actors are changing how they come to market. The bad actors are changing how they do attacks. And if you expect that the tools you used to use are going to be able to protect you when they change, you're going to find yourself on the other side of a ransomware attack.

Brian Moody: Well, that model, and I think the other shift is, is you made a comment. You said, if you're trying to build this yourself, you're going to fall behind because maybe others aren't. And I think the shift that, again, that you saw so long ago was is that most companies are going to come to you and most of those platforms and we mentioned a couple of those OEM names. What they do is they sell you some licenses and they put their infrastructure up, but what do they do? They notify you that something's wrong and who's fixing it? Who's responding, right?  

‍

Because it's all about how quickly you can respond. That technology debt still falls on you. And whether you're an MSP, MSSP, or a partner or a customer watching us today, you're buying licenses. They're helping you manage those licenses. And when something happens and it falls in your lap because you get the email that you need to do something.

Shahin Pirooz: And you may even, like a lot of our commercial technology partners are OEMs, have security operations that you can bolt on to their solutions. We don't consume any of them because we've got our own and we've developed our own approach to how we do things. But I've been asked by partners, you're using this same tool, they have their own SOC, why wouldn't I just use them?  

‍

And when we do a comparison of what we're doing versus what they're getting, those solutions are doing—their SOCs are maintaining hygiene of their portal, their console. They're making sure that there's no stale stuff in there, that the agents are updated, that if there's an alert, they're triaging it. In some cases, there's a little more threat hunting, but they do not go outside of their console. So that's not a SOC. That is a backend operations team for a tool.  

‍

That's the fundamental challenge I think the market is getting confused by, is that there's a lot of companies that think if I'm using tool X and they have their own SOC offering, then that's all I need. What happened to your email security, and your DNS security, and your network security? Who's covering the SOC on those things? You have 6 SOCs or do you have 15 SOCs?

Brian Moody: And who's responding?

Shahin Pirooz: Yeah, exactly.

Brian Moody: And I think that's the other piece that I think that, again, you called out years ago. Continuous incident response has been a part of the WhiteDog platform from the beginning.

Shahin Pirooz: For 8 years.

Brian Moody: Right? And I think that's the unique piece is that we notify, right? So we work on the 1-10-60 model, but we notify, but you have a WhiteDog security professional that is responding and that's interacting almost immediately with that particular event. We're not sending you an email telling you, oh, hey, we see this, you got to go do something.

Shahin Pirooz: And it's not just that individual node that's having a problem. If any of our customers—and knock on wood, this hasn't happened for anybody who's on any of our detection and response offerings—if any of our customers get a ransomware attack, we are jumping in and doing the incident response with you. It's not just, hey, we stopped that machine. Good luck with the rest of it.  

‍

We're going to get in and walk you through what you need to do in Active Directory, what you need to do on the network, what you need to do—areas that we don't touch, areas that are not our expertise. So it's important to get an idea of when you're looking at incident response, what's that incident response going to do? Because a lot of these OEM technologies add incident response to their services as a modular add-on, as bolt-on, if you will, where you can buy a retainer. That retainer gets you hours and hourly whatevers. This is included and included at less than the price of the tool that you would have subscribed to from that manufacturer to begin with.

Brian Moody: So I think, the other aspect, really is around—you said, you can build it. So as you analyze how to go to market, I think the complexity of security today has really raised the bar. As I talk to partners today, and I think why partners engage us now is, the barrier to entry to implementing a security offering is huge. If you're a user, a customer, if you're a partner, I don't think it matters. I think the cost today of implementing a security solution is the barrier has become you know, quite high. And you said it, and I would almost ask the question, why would you want to? I mean, if you need a CRM today, do you go build one? No, you—as a service

Shahin Pirooz: You go consume a SaaS-based—

Brian Moody: CRM solution. Same thing. You know, I mean, many years ago we saw, right, cloud, this whole idea of on-prem and hybrid. You know, we were building our own clouds. Are you going to build a cloud today? Absolutely not. You're swiping your credit card. You know and I think that's the unique thing now, again, I think you saw years ago is that we've created a platform that around security is the easy button. Is very quickly you can—

Shahin Pirooz: Swipe your credit card.

Brian Moody: You can swipe your credit card. You know, month-to-month billing, that's the other aspect that's unique about WhiteDog is there's no long-term contracts, right? You think about every one of those tools, every one of the manufacturers. I had a partner call us the other day because they had a smaller deal of 25 or 30, SentinelOne says, we can't quote anything under 250.

Shahin Pirooz: $2,500 revenue.

Brian Moody: So the point is, I think, is that, you know, why would you? The economics, the reduction of technology debt, the efficiencies, and then having that 7 by 24 security operations included behind, that you don't have to staff to, it makes it just seem like—

Shahin Pirooz: No-brainer.

Brian Moody: No-brainer.

Shahin Pirooz: It should be. We literally have partners who are like, I don't understand why everybody's not doing this. And we would love to understand that too. So if anybody out there knows, call me.  

‍

My favorite line at a conference, coming back to continuous incident response, I think I've said this before, but I was having a boardroom session and talking to a group of folks and one guy says, Why are you giving continuous incident response away for free? Does your product suck that much? And I had to pause for a second and make sure I understood the question. And a few people in the room started laughing and they said, no, because he's that good. I said that.

Brian Moody: Well, for many that may not remember the Maytag man, you know, he was sitting at his desk and he wasn't doing very much because the idea was that the machines didn't break.

Shahin Pirooz: Yeah, I'd like to say it sleeves out of my vest because we hope to never have to do an incident response and we do everything we can to prevent that from happening. But should it happen, our commitment is that we're there for you. Right.

Brian Moody: So let's wrap this up. I think we've run around this mulberry bush quite a bit. So if you're dealing with tool sprawl challenge, love to talk to you. I think we can help. If you're looking at, as an MSP wanting to get into the security space, I think absolutely we could help you almost overnight be able to bring a high-quality enterprise-level security platform to your customer. Would love to talk to you about that.  

‍

But I think this challenge, we've talked about it over and over for years now, and it hasn't gone away. I think customers, partners are still dealing with the challenge of, I can do this myself, I can put these tools together. And we say, great, go for it. We'll talk to you in 6 months.

Shahin Pirooz: Yes. That happens more times than not.

Brian Moody: Because I think you'll be back. But happy to discuss this with you. Reach out to us. But definitely kind of a challenge, but there's a solution. And I think the WhiteDog enterprise platform fits the bill pretty well.

Shahin Pirooz: And we do have an asset that is—that's available. You'll get a link to that at the end of the livestream when the livestream is posted.  

‍

The asset talks about the CISA security maturity model. There's some market research information in there around what the tool sprawl problem is and what the challenge is and when the triggers hit. So a little bit written documentation you can read about what we've talked about today in addition to the livestream. And we would love, as Brian said, we would love to hear from you.

Brian Moody: So thank you for joining us today. It feels like I'll talk to you in a few hours, which will be May. These are going by very quickly, but thanks for joining us today. Have a fantastic day, and we will talk to you again in May.

‍