SS-RPRT-140: Consolidation and Merging in Cybersecurity

Episode 140 April 08, 2024 00:43:36
SS-RPRT-140: Consolidation and Merging in Cybersecurity
Security Serengeti
SS-RPRT-140: Consolidation and Merging in Cybersecurity

Apr 08 2024 | 00:43:36

/

Show Notes

This week David and I discuss an article from Venture in Security on how other industries have consolidated, and what lessons we can take from that into Security.  It's more interesting than it sounds, I swear!

Article - Three types of consolidation in cybersecurity, and how monopolization and commoditization are shaping the industry of tomorrow

If you found this interesting or useful, please follow us on Twitter @serengetisec and subscribe and review on your favorite podcast app!

View Full Transcript

Episode Transcript

Transcript is AI Generated - There are certainly errors, like our names. 
 Matthew: [00:00:00] Welcome to the Security Serengeti, we're your hosts, David Schwindiger and Matthew Koehner. podcast, leave us a lovely five star review and follow us at SerengetiSec on Twitter. 
 David: We're here to talk about cybersecurity technology news headlines. Hopefully we've brought some insight, analysis, practical application that you can take back into the office to help protect your organization. 
 Matthew: Views and opinions expressed in this podcast are ours and ours alone and do not reflect the views or opinions of our employers. 
 David: Well, we regret to inform you that our announcement last week was premature as we've revealed the acquisition too soon, SNL has backed out, backed out and now we're back at our day jobs. 
 Matthew: Oh, there's a bright spot in there. Turns out SNL doesn't pay very well, so we're actually back to making more money than we would have. 
 David: Yeah. My check bounced. 
 Matthew: Oof. Thanks. I do really think we could have brought up the level of maturity. And humor there though. 
 David: Oh, we're way more mature than they are. 
 Matthew: Weren't we just talking the other week about making an offensive version of the security news [00:01:00] podcast? 
 David: offensive cyber security. That would be so much fun if we wouldn't get fired. 
 Matthew: Yeah. Well, 
 David: All right. So this week we're talking about three types of consolidation and cybersecurity and how monopolization and commoditization Are shaping the industry of tomorrow. 
 Matthew: yay. 
 David: We've got this from Venture Insecurity. And the article was written by Ross Halaluk, I 
 Matthew: I don't know. 
 David: Halaluk. 
 Matthew: I don't know. 
 David: You know, I thought we had done a different article on Venture Insecurity, but I couldn't find anything in the catalog. 
 Matthew: We have. I mean, I've, so I started following this blog about a month and a half ago or something. And I'm pretty sure we've talked about something, 
 David: Yeah, I did a search and couldn't find one, 
 Matthew: maybe we talked about one, but we didn't pick it. 
 David: Hmm. Could be. 
 Matthew: Oh, you know what he did? Cause he did one of the articles. I want to talk about a hero heroism, hero culture, hero culture and [00:02:00] cybersecurity origins impact and why we need to break the toxic cycle. 
 On January 24th, that is one that I put up for possibly being in the podcast and we ended up not making it 
 David: Ah, okay. Because it would make 
 Matthew: you didn't want to talk about hero culture. 
 David: It wouldn't make you sad because you're the hero and, you know, you want, don't want to be destroyed. You're like was it Mr. Incredible Incredibles cartoon. 
 Matthew: What? 
 David: All right. So we're going to take a deeper dive into the topic of consolidation, explaining what the different types of consolidation are and what it means for the industry and why we're unlikely to end up with one or two tools. So the three types of consolidation that he references are industrial, industrial, industry consolidation spend slash tool consolidation, and then platformization, which I guess he invented that term. 
 Matthew: I've never heard of it before. For sure. Sorry. I'll try and calm down. 
 David: All right. And while each of these is independent, they are [00:03:00] interconnected. So the first one, industry consolidation, this is probably the one that most people are familiar with, where large companies buy small companies. Typically startups, and this is the driver of most of the M& A activity that occurs within the industry. 
 Every once in a while, you get large, larger, larger players merging together, but usually it's large companies buying startups. 
 Matthew: Yeah, he did provide some examples of large companies merging together, but that's not something that I think we have seen in this industry. So that's interesting. 
 David: Now, and the reason this happens is incumbents, which are the large companies, they have well established distribution channels. , it simplifies plug and play for new products and features into their existing systems, which is, Versus creating their own. And a lot of new products are features and not actual products, 
 Matthew: Yeah, we've seen some examples of that recently. UBA started off as a product, but it turns out it actually is just kind of a feature of SIEMs SOARs that was, everybody was building a [00:04:00] SOAR. Turns out that's really just a feature of a SIEM, if you're Splunk, or ticketing system. 
 David: right? And we're seeing these being sucked into, you know, existing tools like SplunkBotPhantom IBMBot, 
 Matthew: Palo Alto bought to Misto, Mandiant bought Veradon. So it turns 
 David: that's the tech simulation. But IBMBot Busch Schneier's tool his SOAR tool. What the heck was it called then? Oh, man. Resilience, resilience systems, or 
 Matthew: yeah. Yeah. That was mostly a ticketing system. That started off as a ticketing system and like a checklist compliance activity, and then they added the source stuff into it. 
 David: yeah. So you see this quite a bit. And that's because these large companies, they aren't really hives of innovation. That's what happens in the startups. They are, you know, you're rarely going to see innovation actually occur in house in these large organizations. They get their, their innovative ideas by acquiring smaller startups and pulling that [00:05:00] in. 
 Matthew: Yeah. 
 David: And this encourages the creation of more point solutions. Because as he referenced in a different article that will be linked in the show notes most startups are startups and they're never going to be anything but that because they're designed to be acquired. They aren't actually, when a startup is founded, it's founded to be acquired. 
 It's not founded to actually start a company. Let's say there are very few startups today that are actually created as a business. They're just what I would call corporate bait waiting to be eaten. 
 Matthew: Yeah. And I honestly think that makes a lot of sense. Because generally speaking, I mean, we've talked about business opportunities that we've seen. Haven't started the company yet, but who knows, it might happen, but I don't think so. When I, when I think about something like I want to solve a problem, I'm not looking to build like a lifestyle. 
 I have no desire to be a CEO, except for maybe the overwhelming power and responsibility of such a position. But like, yeah, [00:06:00] I mean, I think the point about building the company, when you want to build a company, that's almost a, that's almost a egotistical position where you're like, I want to build this, this thing that represents me and my values. 
 So maybe I'm reading too much into it. 
 David: Now, I wouldn't necessarily, well, maybe, but what I'm thinking about, and this will come into the conversation, maybe more when we talk about the platformization thing. But if you have, you know, if you're a security professional and you're going to solve a point solution or whatever and what you're really more interested in solving the broader problem with cybersecurity actually founding a company would be a better idea because then you can go into the idea that. 
 Sure. We're going to start with this point solution, but then we're going to build on that. And we're going to expand and we're actually the overall goal for the company is not to build this individual product, but to build a platform, which is going to have multiple parts in it. We're just going to start with this part here and build from there. And that way you won't have all these challenges with [00:07:00] the larger company buying parts that don't necessarily aren't designed to be fit together. 
 Matthew: Yeah. I think a lot of the fit together part, though, could be solved through adopting good, consistent that's what I'm thinking of, like, like, Like Mac, if he had that layer, 
 David: Yeah. The tie. 
 Matthew: yeah, where you, where they would, or they could conceivably like combine, like, I think that a lot of, I think the products need to start off with something like that in mind, like, yeah, we, we're going to start building this product and let's pick a framework that already exists or like a major vendor that already exists and just go ahead and make sure that we are from the start adapted to that. 
 David: Well, I would like to see the establishment of. I mean, for lack of a better term, universal framework like that, though, you know, because I'm thinking about if you buy an air compressor, then there's universal couplers for you to [00:08:00] use any tool with that air compressor. Or if you have an outlet in the United States, anything you buy that's got an electrical plug on it is going to fit that outlet. 
 Matthew: Yeah, 
 David: Now, if you, if. If every tool that was constructed had a framework designed for its inputs and outputs, then any product could be acquired by any other company and immediately being be plugged into that ecosystem. Now, if we, and if companies also thought about that, in every company build to that way, You could actually get away with purchasing the best, you know, the quote unquote best tool for every solution because they would all naturally integrate because they've been designed according to that framework versus now where you want to buy a platform because those interconnections are already designed and built together or ready to work that way. We just need to build that framework and then force companies to adopt it. And I think this could be something that [00:09:00] could be driven by customers, especially larger customers, if they put it in their requisition documentation, their requirements to say, Hey, there's this framework that says. 
 Standardized the inputs and outputs for any kind of security tool. And if we're going to acquire a security tool, it must abide by that framework. That's on our checklist. Say, you know, if you don't abide by this framework, then we're not going to acquire your tool. 
 Matthew: Then they have to actually abide by it, not acquire the tool, 
 David: Right. Then they have to 
 Matthew: ignore it when they're like, Ah, this one took us out to the nicest steak dinner. 
 David: Right. And that's the thing is that smaller companies won't be able to really enforce that too much. But if you got larger corporations that or the government that forced the adherence to that framework, then we could actually get somewhere where It would be much easier for you to acquire the proper tool for your organization and fit it naturally into your existing ecosystem rather than saying, well, we're going to buy this tool from Cisco because we already have the Cisco [00:10:00] ecosystem. 
 It's going to plug and play much easier versus actually buying the one that we want, even though that would have to be completely independently managed and integrated and everything else. 
 Matthew: If only. 
 David: But he describes this, this process as, continuous and linear. So after a sufficiently long time, we would end up with only a few large players. The number of new entrants every year is higher than the number of M& A transactions though. So even though you have, you know, 10 M& As in a year, there are 20 new entrants that come into the market. 
 So they still aren't gobbling up everybody at the same rate at which new companies are being produced. 
 Matthew: Yeah. And in the article, we didn't go into this in detail 'cause as David pointed out, this is a very long article and we've already gone long enough. We've got like five pages on this. But he did have some examples of industry consolidation and the defense industry, the pharmaceutical industry, and the banking industry, all of which were for [00:11:00] different reasons. 
 The defense industry was because the government stopped spending as much money on defense. So a whole bunch of companies consolidated into a few, the banking industry was because of deregulation. 
 David: I just like call bullshit on that first one because the defense industry spending has never decreased. Period. 
 Matthew: I thought, well, he talked about that whole, like, 
 David: No, there was a threat. 
 Matthew: Oh, there's a threat of 
 David: the collapse of the Soviet Union 
 Matthew: Oh, I 
 David: Hey, we're not going to spend as much because now we don't have this great enemy. That's the Soviet Union. 
 Matthew: Now we have a whole bunch of little ones. 
 David: And well, we're going to create new enemies since we don't have a big one anymore. But if you look at historically, 
 the defense spending budget has never, ever decreased. 
 Matthew: Gotcha. So that, so that was the, well, okay, so there was the threat of less spending for that one. For banking, the consolidation was driven by deregulation. Banks used to have to be, you know, only work locally to them, and then when they deregulated and allowed them to work nationally and internationally, they all were acquired and merged. 
 [00:12:00] And then pharmaceuticals the merging of pharmaceuticals is driven by the extremely high cost of developing new drugs. 
 David: Well, one thing 
 Matthew: cyber security. Doesn't 
 really I would like to say about the banking thing though, is that the deregulation was not an entirely bad thing based on what happened during the great depression, because of that law that said that banks could expand outside of their state. That means that localized problems would then cause entire banking systems to collapse, you know, because if you have a bank, which only exists in Iowa and Most of the patrons of that bank are farmers and it's hit. 
 David: And I was hit by this huge cold snap or whatever that destroys their entire corn crop in one year. Then the farmers go under and then the banks go under to follow them. So. 
 Matthew: I'm sorry, God. 
 David: So actually deregulating it so they could so they could spread their, their their banking products across the larger area, but then not centralize their customer [00:13:00] base as much, allowing them to withstand isolated shocks like that. 
 Matthew: It's kind of like the and just insurance industry. You don't want to be insuring too many things in one place. 
 David: Right. Exactly. You know, an insurance company that only exists in a hurricane ridden area would probably not last long. 
 Matthew: Yep. Do you see a, well, nevermind, we're not talking about that. Nevermind. Nevermind. Stay on 
 David: way off tangent 
 Matthew: Stay on target 
 David: Red leader. No, red six. I'm sorry, red six, stay in target. So the next consolidation is spend slash tool consolidation. And this is, I'm sure a lot of people who work in large organizations have done this at least once. 
 Matthew: or talk about it endlessly. 
 David: So security tools are looking for ways to reduce the number of tools. 
 Okay. 
 Matthew: Yeah. 
 David: And of course, this is typically driven by cost savings and coverage deduplication and of course. This would not be much of a problem if the tools were actually properly [00:14:00] configured and kept up to date. And customers knew the capabilities of the that the vendors offered, 
 Matthew: Yeah. And this comes to mind to me, especially after the, the blue team report that I think we read two weeks ago, or maybe it was a month ago where they talked about how almost every customer had, I think it was the, the majority, like more than 50 percent of the attacks were detected by their tools, which strongly implies to me that even in the default configuration, most of these tools are more capable than the teams that are implementing them. 
 Maybe a little harsh, but. 
 David: but not surprising. But it may, it may not even be so much that they're, they're better than the teams, but that the team's time or, or, or that, or money that they can spend on actually. Configuring those tools is, you know, not as much as they would like. 
 Matthew: but yeah, that's a leadership problem because we've both seen this and in our lives where a tool is bought, it's [00:15:00] implemented and then they quickly move on to the next cool tool and they don't actually spend the time to correctly tune it and, and make it work with the environment. Very frustrating. 
 Invalidated 
 David: that's the planning problem where they say, well, we're going to buy this tool and they say that a tool is deployed. And once the engineering team has finished deploying it versus saying the tool is deployed, once the engineering team's deployed it and we've configured it for the way we want it to be configured 
 Matthew: it and, 
 David: right. 
 And basically what you call operationalized it. And I think that's the problem because they build these deployment plans for tools. And it's only up to the point where the engineering part is done. The actual deployment plan does not incorporate the backend part where it's actually operationalized by the consumers. 
 Matthew: And from what I've seen on operationalization, I don't know how, I don't know if that word came out right. 
 David: It did. 
 Matthew: The operationalization can take longer than the deployment, like an [00:16:00] acquisition and deployment of a tool might take six to nine months. Like operationalization of it may take longer than the deployment, depending on the tool. 
 Some tools are not terribly difficult to deploy and others are quite, like operationalizing a sim tool or a sore tool is going to take. Years. 
 David: right. Well, another problem with that too, is that a lot of times the consumers of the tool, they don't know what they really want in order to define what they would call operation operationalized. It is like really, it's almost German and it's the way it's built but they can't even define what they would, what they would say to say it's fully deployed for them or properly configured for them because they really don't know what, what they want. 
 Matthew: Who does? Who knows what they want in this world? 
 David: Well, usually what they want is they want this one thing, right? They want it to do this generally, this one thing without fully understanding the full scope of what that means or all the aspects of the tool that they acquired outside of that one [00:17:00] thing. But the way that they describe are this as. A subset of the tool consolidation is a thing called bundling. And this is typically a strategy for larger players like Microsoft or Cisco. Where, you know, with the Microsoft E5 license, you get this, this and that, and it's a different Cisco bundles. 
 You'll get different, different parts that you may buy a security bundle that includes, you know, ice and maybe AMP or different security tools together. But the, and I don't know, I can't even speak to how many times I've gotten briefings from these large vendors and say, well, you already own this, but you're not using it. Because there's so much so many things in that bundle that some of it ends up getting wasted. But he describes the spend tool consolidation as a continuous and cyclical process. And it, and the way that he describes this, the cycle is basically. You get a new attack vendor [00:18:00] or a new problem area. You get a new solution to address that one thing. Then another one of those comes along, then another one. 
 And eventually the security stack is too big and people are like, okay, this is unwieldy, we need to reduce this down. And then once it's down, then you run through that entire cycle again. And, and part of that also may be that you've bought a point solution to fix a problem, but then that problem then gets fixed by a feature, which is, you know comes as part of a larger platform that you already have also. So maybe you turn that feature on over here at Microsoft and you get rid of that point solution that you purchased. 
 Matthew: Yeah, I think that the big platform companies really rely on that, and I think that seems really important to me. I don't think I've ever seen a company fully exploit their toolset, so adding it into a larger tool like that probably is easier to operationalize as opposed to having [00:19:00] 20, separate little tools all running around, none of which connect with each other worth a darn or operate together. 
 Together. 
 David: Yeah. Well, if you know that feature exists anyway, 
 Matthew: I'm oh man, like you, I am constantly finding out about new stuff that exists in Microsoft. I had no idea was a thing. 
 David: well, most people are Microsoft. Don't even know the answer to that question. 
 Matthew: Yeah. Well, and what's even actually, you know, what, it's funny too, is trying to find some of the stuff. Like even if you know, it's there trying to figure out which portal it's in. That can be a pain in the butt as well. 
 David: Yeah. And Microsoft is your, that's just a mess. Their permission sets are even terrible. 
 Matthew: Yeah, yeah, it's a giant pain. 
 David: But the risk of the whole process of the spend tool consolidation is vendor lock in, you know, so once you have a platform vendor, that's providing all these things, it makes it much more difficult to switch vendors. And we touched on this a minute ago that you settle for average [00:20:00] solutions instead of the best of breed. 
 Whereas if you had that framework that I was talking about before, it would be much easier to pick best of breed because they would all integrate together. But the, but the whole thing with the, the, the concept of best of breed though I think may kind of average out because often the best of breed tools like we mentioned a minute ago are not configured to be their best. They are not properly operationalized. The, their configuration may end up being actually configured to turn out to be average, not actually best of breed. 
 They may be breast of breed, but they're not configured to be best of breed. They're configured to be average. 
 Matthew: Yeah. I, I definitely, as I've gotten older, I've come around more to. The idea of buying into a platform that works, even if the individual tools are not the best 
 David: You can have, I have as well. 
 Matthew: yeah, just because having it all work together is more important. Because again, like you said, nobody, even if you buy the best debris and then you don't spend your time configuring it and making it work, then.[00:21:00] 
 David: Well, cause that's the thing with best of breed too, is they take a lot of work and configuration to get them to work optimally for wherever they're deployed as well. And no one spends that time. 
 Matthew: No, they really don't 
 David: and one thing he noted here is that reducing the number of vendors doesn't necessarily reduce the number of tools that you have either. It just reduces the number of people you buy the tools from. 
 Matthew: which I've actually heard of people doing that specifically who are like, ah, we need to reduce the number of vendors we have, which I don't really understand. I understand what benefit reducing the number of vendors you have does for you 
 David: your accounting department doesn't have to work as hard. 
 Matthew: but I don't care how hard they work. 
 David: Well that's who you're doing that for. 
 Matthew: All right. Fair enough. 
 David: All right. And the last section that he talks about is platformize, platformization. Which is large vendors working to assemble security platforms, [00:22:00] integrating a broad set of disjointed tools, tools into one platform. 
 Matthew: Have you seen a good successful platform? I mean, I know that Halo Alto is trying to do it with XIM. They're combining their network telemetry with an EDR product and calling it XDR, and now they're building in the XOR to that all into one platform. Splunk seems to be doing the same thing. They, they, they've got their SIEM, which has the tentacles and everything, and they've added Phantom and they're adding, they're purchasing, they purchased a Thread Intel vendor and they're, Purchasing a bunch of other stuff trying to turn Splunk into a platform like that. 
 David: Well, in the security space, I'm not sure, but I would say that a reasonably successful platform now is ServiceNow. ServiceNow, they got a ton of modules and they're pretty much designed from the jump to integrate and work together. And plat and ServiceNow is generally building their stuff from scratch. 
 As part of that, they are not [00:23:00] acquiring tools or whatever for their modules. They're building it onto their platform themselves. 
 Matthew: See that? Makes sense is the right way to do it because I feel like I'm thinking of, I'm thinking of Splunk when Splunk bought Phantom, it took them a year, a year and a half, maybe two years to actually rewrite the code to such where it worked in Splunk. Like, why did they buy it then? Why didn't they just build it themselves? 
 If it takes them that long to rewrite the code, I would think a company with deep pockets like Splunk could just hire the people to make it happen like, like ServiceNow is doing apparently. Yeah, 
 David: probably would have been better off simply hiring the sore architects that designed it and say, Hey, bring what you learned from doing that over to Splunk and pay them a ton of money to build it from scratch. On Splunk's platform, taking everything they learned in building that, the phantom the first time. 
 But do it, 
 Matthew: better this [00:24:00] time. 
 David: yeah, build it better and build it native to Splunk. I think the thing is that large companies are just impatient. It's that it's the whole you know, MVP, they want to get the MVP as soon as possible and to get their foot in the door in the market. You know, everybody's, everybody wants a SOAR. 
 So we have to get a SOAR right now. So let's go buy a SOAR and then we could say we have a SOAR and we can sell it. I think it's a matter of impatience versus really wanting or having a desire to build a quality product. 
 Matthew: Yeah. Cause it definitely does not, it's not fast at all to get it built in and, and, and, and integrated with what you have is the opposite of fast. 
 David: Yeah, but they can create a press release that says, Hey, we have acquired 
 Matthew: We now have a sore. Yay. That's fair. You're right. I didn't think about that. That is, that is the most important part. 
 David: All right. And, and he describes the [00:25:00] platform ization as a unidirectional strategy led process. 
 Matthew: So many buzzwords in there. 
 David: So vendors are adding new products and capabilities into their portfolios. 
 Matthew: good for them. 
 David: And of course they will claim it's a seamless experience. And security teams are always looking to integrate a cohesive experiences. You know, like we said, we'd really like all of our tools to work together. 
 Matthew: Yeah. I would pay good money for tools that actually work together. Yeah. 
 I'd pay my company's good money for this 
 David: to get tools to work together. And he says, this is a strategy led because the vendor have to, has to embrace the concept and specifically say, this is the way we're going to go. 
 Matthew: is the way 
 David: Of course. Right. But the problems he says there with this platformization is monolithic platform becomes less secure as it grows. 
 Matthew: more tech surface, 
 David: Yep. The [00:26:00] bigger the platform, the less efficient the bigger the platform. The more technical debt. 
 Matthew: especially when you're assuming technical debt from other companies. Like when you, when you buy somebody else's platform, you don't know what lives under the hood. 
 So versus if you build it yourself, at least you've got some, you know, historical knowledge because. 
 David: I can't really go get into detail on it, but I've seen this firsthand. Around that. And I've also seen this next one firsthand. Poor support channels. Freaking try to get Microsoft to do a damn thing. And they're, and Microsoft's not the only, the only one. Once a company gets to a certain size, The, the, the, the possibility that an individual customer will have any influence on them is going to be almost zero. And for, and for, and for a company like Microsoft has is not customer focused, it's even [00:27:00] worse. 
 Matthew: I, I, yeah, I don't have too much experience and I feel like all companies get difficult manage once they reach a certain point, at least in terms of teams. And I feel like there's also some culture shock around bringing a small startup style team into a large company. 
 David: Hmm. Yeah. They don't last 
 Matthew: Yeah. Well, and that goes back to the whole, like now you don't have that legacy information. 
 All the tribal knowledge is gone. That's the technical debt. And that leads right into your next your next point here. 
 David: that large platforms are insanely hard to implement. 
 Matthew: Yeah. Or to maintain, right? Oh, and I'm, Oh, it is implement. Sorry. I, it's funny. I saw implement, but I thought in my head maintain. Yeah. Yeah. Yeah. 
 David: and of course, a large platforms are expensive. And I would say, as I was saying before, that you're going to pay for features you will never use and may not even know exist. 
 Matthew: I feel that with Microsoft. Splunk too. Splunk, I'm always finding out about new stuff that I didn't know they had, [00:28:00] you know, some company they bought or. 
 David: That's like a, you know, if you have a large company that you deal with like Splunk or, or Microsoft or whatever, it would be a good idea to have regular conversations with their account team to understand what you're buying and what's there and maybe even do that monthly or quarterly or, or something just to try to get a handle on that. 
 Matthew: think, I think how often you have that conversation depends on how often or how, how quickly you can operationalize those bets because having a, you know, a monthly conversation, finding out about stuff and you're like, ah, we haven't even finished putting in the other stuff 
 David: I think you have the conversation regularly and then what comes out of that conversation is a project to implement whatever you think is the most value that you learned there. And maybe you don't have that conversation as frequently until you operationalize whatever you learned in the last one, but considering they're constantly changing it may be beneficial for you to have that conversation, conversation regularly. 
 So then you can [00:29:00] prioritize you know, what they 
 Matthew: when they release something that addresses a particular need you have. You're like, Oh, Oh, I've been looking for that. 
 David: Oh, that's fancy. 
 Matthew: It is fancy, shiny. Let's do it. 
 David: And having a large platform like that, you end up with a vendor lock in that we talked in, talked about a minute ago as well. It's harder to switch. 
 Matthew: But yeah, but I think people switch too often before they need to, because this goes back to what we're talking about before where people aren't utilizing the whole platform worth a darn Like, I think that you really need to have like a really good reason to switch, not just, you know, Oh, we've got new leadership and they used, I don't know carbon black. 
 So we're going to use carbon black now, but I guess good luck pushing back against that. 
 David: Yeah. I think what happens is, you know, you, you get a new tool, you fail to operationalize it. So then it doesn't live up to your expectations. So you become disillusioned with it. And you're like, this is crap. I want to replace it with something else that's [00:30:00] new. And then the same, the cycle repeats versus saying, well, all right, we're going to knuckle down and truly operationalize it, and then, you know determine that it doesn't meet our needs or not, but of course, if you have a really good requirements document, then at least once you have the product, you can I mean, you should have the requirements document, of course, before you get the product. 
 And then the requirements document may be a living thing after you've acquired the product to say, okay, well, we realized now that we want this, this, and this. So you just start adding onto those requirements and always comparing those requirements against the tool to say, You know, these are what we think it really needs to do, and then see if it does it or not. Especially before you jump ship. 
 Matthew: I mean, I'm just going to, let's just buy the, let's just buy the coolest one. We find 
 David: You know, buy the coolest one you find, and hire a bunch of contractors to do the work, and you know, you take a nap, and have them come, come wake you up in your hammock, when, when, whenever they're done. 
 Matthew: that sounds like a management decision. We're managers now. 
 David: Yeah, speak for yourself. But of [00:31:00] course, the larger the platform, the more vulnerabilities it's going to have too. So you're going to have actors wanting to attack. Your security platform, because if they can get into that platform, then it may open a whole bunch of doors for him. 
 Matthew: Yeah. 
 David: And you know, like ServiceNow, if a platform is built by one one vendor building it from the ground up, it's going to be much more robust and integrated and scalable versus these add ons. 
 Matthew: And I had a, I had a little note here saying, does anybody actually do this? But you've already answered that question. 
 David: Well, but ServiceNow is not technically a security company, so it's kind of outside the scope here, but 
 Matthew: That's fair. 
 David: All right. And his last point for the article is every industry tends towards monopolization. And of course this, this section starts off with the U. S. government understands that it needs to do whatever it's in within its power to defend the nation's economy and critical infrastructure. 
 Matthew: Especially if that means You know what, nevermind. No, I'm not gonna make that comment. Number one, number two, I already said that we're I'm [00:32:00] not gonna Nope, nope, nope. I 
 David: So they may give large, you know, what he calls blanket go ahead. For large companies to buy whatever they want so they can do as much consolidation as they want. And the government, 
 Matthew: the defense companies. 
 David: well I'll, I'll make my point here after this other quote, and where he says competition and a healthy market economy are great. It remains to be seen if in the eyes of the government, it would be more valuable than the nation's security. And I think the government, big government loves big business. 
 Because it's much like foreign policy where the United States government would much rather deal with a dictator in a foreign country than a democracy in a foreign country. Because if there's a democracy, then they actually have to work to convince all the citizens to support a concept or that is then going to support the politicians that would support the concept that the United States wants them to. 
 Whereas a dictator, they just have to come in [00:33:00] with a suitcase full of cash. Give it to the dictator and say, Hey, this is what we want you to do. And he does it. 
 Matthew: it doesn't sound like any government I've ever heard of. You have to convince the people. It's weird. 
 David: Yeah, that's a ridiculous, terrible idea. 
 Matthew: What drives monopolization in security? It's easy to start a new security company, especially since most security related products are software nowadays with everything in the cloud, but unless you're starting the whole new technology, there are a large number of incumbents that are currently in the majority of people who might buy your technology. 
 There's fewer buyers for cybersecurity technology than you'd think. Most small companies have, you know, antivirus and that's it. Firewalls and that's it. I think APN firewalls have actually probably done the best job of pushing adoption all the way down to small companies. Like even the smallest companies kind of know like, Oh, I need AV. 
 I need to get my Malwarebytes subscription because 
 David: those companies have done [00:34:00] well at is simplifying implementation. You know, implementing an AV solution is pretty straightforward and not that hard to do the same thing with firewalls. You just have to understand your traffic. That's the hardest thing with firewalls. 
 And I think that's one of the things about and the larger companies also is they may say that they're built to scale or designed to scale, but they're not, they're only designed to scale up, right? Right. So Microsoft has an E 5 license, but only a large company is going to get all the security benefits that Microsoft proposes is an E 5 license, right? 
 Matthew: Oh yeah. And even 
 David: company, you, 
 can't, you can't afford that. So you're going to miss out on a lot of those security aspects that are only available in an E 5 versus building it to say, Oh, if you're a small company, you get those features, but you pay less according to the number of employees you have or whatever, the more employees you have, the more you pay or more data you use, the more you pay or something like that. 
 Sorry. Terrible. The licensing concepts are all out of whack. 
 Matthew: actually sounds like a nice little [00:35:00] business opportunity because I took a look at NAICS. com, which I actually have no idea what that website is, but it had a list of how many businesses by employee there were. And there were only 24, 081 businesses with over a thousand employees in the U. S. And I picked a thousand. 
 Because that seems like that's the size that the company might have a dedicated information security group, although at a thousand employees and information security groups, probably two people, three people and there's 16 million businesses under 20. So that kind of sounds like if you can simplify. 
 And reduce your licensing, like Malwarebytes has done a really good job of this, like they aggressively target mid sized and small businesses. So it seems like there's actually a business opportunity. I don't know, obviously a small business may not need a sim or something like that, but there's probably, probably something there. 
 David: Yeah, you could XDR those guys, right? 
 Matthew: Yeah. Yeah. They convinced them that their AV is not good enough and they need to move up to the next, the next new thing. So 
 David: Yeah. But everybody's chasing that jar, that [00:36:00] large pot of gold with the bigger companies. 
 Matthew: They want those big those big deals so they can get their vacations or 
 David: Yeah. Well, it goes back to that whole thing about, you know, having fewer choke, throats to choke. You know, if you have a hundred large customers versus a thousand small customers, it's much easier to manage. 
 Matthew: And you can hire fewer salespeople too. 
 David: Yep. 
 Matthew: So back to what drives monopolization and security cybersecurity is an industry that works on trust, especially how critical it is. Considering how difficult it is to rip and replace something like a SIM or an EDR, it's a lot easier to turn to an existing vendor for a new capability rather than trying some new startup. 
 I've definitely heard this myself in the past when looking at a startup that has a cool new product and they're like, eh, but we would rather use Cisco. Or what's that, what's that statement about no one ever got fired for buying 
 David: By an IBM. 
 Matthew: Yeah, 
 David: Well, you know, that's something else that we, you know, mentioned a minute ago is the acquisition process too. 'cause if you have an existing vendor, then you don't have to go through an NDA process. You don't [00:37:00] have to onboard them as a vendor. There's all sort of other bureaucratic hoops you aren't gonna have to jump through if you use an existing provider. 
 Matthew: Next item, a large percentage of the cybersecurity companies are venture backed. This leads to acquisition or going public quickly because the venture capitalists want to get their money back. They don't want to, they don't want to focus on, you know, taking their time and building up the, the, the floor beneath the company before they move up. 
 They want to, they want to move fast. Customers want to simplify. We've talked about this before. They want to both consolidate their spending and reduce the number of vendors, which is interesting because the same people frequently complain about vendor lock in, long term contracts, mandatory minimums, and the lack of innovation. 
 But I think the thing is, is what people really want when they want consolidation. Again, we talked about this before. This is a theme throughout here, is they want fewer, better tools that are seamlessly integrated, but that's not what we get. When we buy a platform, we typically get disparate tools created by different companies that have been slapped together to work together in a minimally effective way.[00:38:00] 
 David: You know, something else I just thought of though, as far as the reducing the number of vendors. Is that also reduces your third party risk, depending on what kind of data you're sharing with them, depending on the solution, right? So you don't have to worry about the security of that. You only have to worry about the security of five vendors versus 10 vendors. 
 Matthew: Yeah. It makes it easier for the bad guys too. They have more of your data in the same companies. 
 David: Yeah. 
 Matthew: Trade offs, trade offs. So every product category trends towards commodification. As a product trends towards the other products, it becomes interchangeable. When a vendor breaks out, they make their product different, better in some way, they add new features, and they get better sales, or they get better buzz, the other vendors are immediately going to pursue that and copy those features. 
 He has a number of reasons of why this is true in cybersecurity, but the two that I found most interesting were, because these, these, these hit me hard right in the heart buyers. Quote, buyers find it hard and often impossible to test and empirically validate the claims of different defenders. I'm sure everybody [00:39:00] listening to this has done a POC and knows just how much of a pain in the butt that is to do. Second, quote, the existence of different standards, frameworks, and best practices calls for the standardization of technology. In an ideal world, this would be true, but I feel like it kind of doesn't because there's too many different conflicting standards. 
 David: Well, not only that, but this ties back into vendors want vendor lock in right? So if they can come up with something that's unique to them, then it makes you much harder for you to port whatever you're doing with them to a new provider, whatever that may be. 
 Matthew: I agree. All right. In, in cybersecurity I think the one technology that's fully commoditized is antivirus. It's all basically the same. In fact, according to the author of this post, many commercial vendors are actually reselling the same generic AV engine as their own. There's only a dozen or so actual different antivirus engines. 
 David: Oh, nice. You know, that's interesting if that's true though, because I [00:40:00] haven't, maybe this is just not something that's happened recently or in recent memory where an AV bend engine has had a vulnerability in it, where if it scans a certain Properly formatted file. It will, you know, be taken over or whatever. 
 Cause then you'd see not just McAfee had an AV engine problem, but McAfee and Bob's AV and Sally's AV or whatever, you know, would it be affected by multiple AV vendors? Because that one engine was bad. 
 Matthew: Yeah, I do. I have seen something about this, something similar to this. And when you look at virus total and you look at, you'll, you'll see like weird named AVs and you're like, I 
 David: Yeah. There's like 
 Matthew: they had, yeah, or 90 or something but yeah, you'll see stuff where you're like that company has an AV and it makes a lot more sense to me that they're just licensing 
 David: Yeah. You could probably, you could probably test that. You take, You know, maybe a dozen, I'm not sure exactly the proper number of files, Mm hmm. but you [00:41:00] run all of them through virus total and see where everything lines up, where these two are always positive. And these two are always negative. And then you could probably figure out which ones are all using the same engines. 
 Matthew: Yeah. Yeah, you could definitely do that. That'd be interesting. Yeah, cause looking over it now, just it's wild and honestly, it's kind of a waste of time if Malwarebytes has a good engine or, or McAfee's got a good engine, like why would Fortinet go and build their own engine? That 
 David: They just license it, slap their name on it. 
 Matthew: Yeah, exactly. 
 David: And that's another revenue stream run for that AB company too. It's like, okay, you don't put our name on it. That's fine. We can live with that as long as you pay us X. 
 Matthew: Yeah. All right. So why does this matter? It doesn't specifically matter. This one is there's, there's no direct takeaways I think to take back other than maybe spend more time and pay more attention to your existing tools and don't immediately rip and replace them. 
 David: Yeah. It's an operationalization is the word of the day. 
 Matthew: Oh God. Say that [00:42:00] three times fast. 
 David: I barely got out once. So no. 
 Matthew: but I thought this was just a really interesting look at the business side of cybersecurity that. Yeah. Kind of affects us all especially with all the mergers going on. So I thought it was a neat article and David agree with me. So we put it in here. 
 David: Yeah, and take a look at the other articles that he's written. Actually reading this one ran me down a rabbit hole. I ended up reading two or three other articles by this guy. Also 
 Matthew: your Saturday reading. Ah, that's 
 David: yeah, work stuff too. 
 And they got distracted by ventures and security. 
 Matthew: security. All right, well that looks like that is all the articles we have for today. Thank you for joining us. Follow us at Serengeti Psych on Twitter, and subscribe on your favorite podcast app.

Other Episodes

Episode 125

October 23, 2023 00:56:38
Episode Cover

SS-NEWS-128: AI Cipher Unsafe, SOC Heroes, and Malware on the Blockchain!

This week we discuss Malware stored on the Blockchain (coming soon to a theater near you!), how to stop Heroes in your SOC (common...

Listen

Episode 8

May 02, 2021 00:40:39
Episode Cover

SS-SUBJ-008: Security 101 - What is Attack Surface Management (ASM)?

In this episode we review Attack Surface Monitoring, discuss what it is and what you should look at if you're reviewing products. Related Webcast...

Listen

Episode 68

July 11, 2022 00:43:26
Episode Cover

SS-NEWS-068: 1 Billion... Records lost!

In this episode, we look at the accusation that North Korea was behind the Harmony Bridge hack, Twitter users behind fished by a devious...

Listen