There are no magic bullets, and every purchasing decision in security comes with trade-offs
There are no magic bullets, and every purchasing decision in security comes with trade-offs
Working with startups vs. incumbents, choosing best-of-breed vs. best-of-suite tools, and buy vs. build decisions for security teams
I often hear people in cybersecurity say that startups are risky, that we need to move towards consolidating all security needs into large platforms, and that if companies can afford it, they may be better off building their own security solutions. The reality is that everything comes at a cost, and every decision introduces its own set of potential risks.
In this piece, I am talking about the pros and cons of working with startups vs. incumbents, choosing best-of-breed vs. best-of-suite tools, and buy vs. build decisions for security teams.
Today’s issue is brought to you by Tines…
CISOs weigh in: How to make AI an accelerator, not a blocker
The push to embrace AI threatens to add more work to the CISO’s plate, but there are huge opportunities for those who get it right. Recently, Tines was joined by CISOs from Elastic and Drata to discuss their current strategies for embracing innovation, while mitigating risk.
From the evolving role of the CISO in AI adoption, to the potential of AI for revolutionizing secops, to the “black box” nature of many new AI systems, the conversation highlighted that AI adoption still holds challenges – and opportunities – for security teams everywhere.
Catch up on the conversation to hear from leading CISO about where they’ve already seen success with AI, and where they’re holding back.
My book, ‘Cyber for Builders’, has been named a finalist for the SANS Institute Difference Makers Award. If you got value from Venture in Security or ‘Cyber for Builders’, or if you’re a fan of what I'm doing, I’d be very grateful for your vote here (it takes less than a minute).
Voting is open now through Friday, October 4 at 5:00 PM EDT (UTC-4). Thanks for your support!
Working with startups vs. incumbents
Advantages and disadvantages of working with early-stage startups
When evaluating an early-stage company, security teams need to remember that there are two types of startups: category creators and disruptors of existing markets.
Category creators are addressing net new needs and building solutions that are not yet being offered by the incumbents. In 2024, a good example of such offerings is AI security as Palo Alto, Microsoft, Crowdstrike, and other large, established vendors do not currently have offerings in that area. Category creators promise that they are going to be able to solve an emerging problem well so that customers don’t have to build their own solutions in-house.
Disruptors, on the other hand, are competing with products that have been years in the making, by offering next-generation solutions. The promise of disruptors is usually affordability, an ability to tailor their solutions to their customer’s needs, and a more modern product experience in line with the demands of the present.
Early-stage startups, be they category creators or disruptors, can offer a great experience for security teams. In particular,
Security teams get a greater ability to influence product roadmap and co-create a solution that fits their needs instead of being forced to adopt a product as is.
Startups are much more responsive and provide better support when it comes to resolving bugs, making changes to the product, supporting customer deployments, etc.
Security startups are nimble and agile, which gives them the ability to move much faster than large incumbents.
Products of early-stage startups are new, and as such they tend to leverage new approaches, architecture, and industry best practices, making them easier to use and integrate with the company’s existing security stack.
Startups are looking for emerging problems that can be solved in novel ways, which often means that they are more than willing to forego revenue in the short term in order to build a competitive product.
In an attempt to be more competitive and appealing to prospects, startups are often substantially cheaper than incumbents who are usually focused on up-market.
Opportunities for innovation and cost savings offered by startups can sometimes be outweighed by the risks of working with early-stage companies, which include:
Many startups lack consistency and the ability to commit to a certain direction, instead spending time adding capabilities that appear to be all over the place.
Inability to execute predictably. Early-stage startups are often overly optimistic about their ability to deliver, and their roadmap changes daily which may make it hard for customers to understand what to expect.
Early-stage startups, especially those that are still in search of product-market fit (PMF), often change their products and approaches in unexpected ways to get to PMF or pursue larger market opportunities. As vendors move in a new direction, the growth path of a security team and the startup may diverge leaving the security team with capabilities the company intends to pull out or is not planning to support.
Since startups have too many priorities and limited resources, areas such as usability and reliability tend to struggle. Things may feel a bit chaotic: the startup may think it’s okay to test new ideas on customer tenants, ship incomplete features, or completely change user experience forcing the customer to re-learn how to use the product daily.
Although the contract cost of the product may be low, the continuous need to work with the customer’s security team on new features, testing, and iteration, frequently adds up.
Despite all the potential cons, in most cases working with early-stage startups is well worth it. Startups are run by people passionate about their cause, motivated to do what it takes to solve hard problems and to ship as much value as possible to their customers. Early-stage companies are where the industry innovation usually originates, and by betting on startups, security leaders are helping to move the field forward.
Advantages and disadvantages of working with incumbents
Whenever I hear discussions about the risks of adopting a specific tool, the product in question is rarely offered by a large incumbent vendor. I think we often forget that while as they used to say in the 1970s, “Nobody ever got fired for buying IBM”, there are indeed downsides to relying on incumbents.
Large security providers such as Microsoft, Palo Alto, Okta, Zscaler, and CrowdStrike, have a lot of resources at their disposal. More importantly, they have had many years to mature their solutions. These factors mean that:
Products offered by incumbents are much more mature, stable, and reliable. They are much less likely to crash in the middle of an important workflow.
Product roadmaps of large companies are much more predictable, and their ability to execute is substantially higher. This is both because they are able to get the resources they need to make things happen, and also because they are expected to show consistent performance to their customer and the market.
Products built by large incumbent vendors don’t change as often and as much. For security teams that don’t have enough time to keep re-learning how the product works, this can be an important advantage.
Established security vendors are much less likely to go bankrupt and disappear from the market overnight. Early-stage startups, on the other hand, are much more likely to fail quickly, and when they do, customers may have little to no heads up that they need to find an alternative solution.
At the same time, working with incumbents comes with a number of notable downsides:
Large security companies are slow to innovate. Although they tend to attract the very best talent from all over the industry, people’s drive and ability to innovate get stifled by the bureaucracy and complexity of a big organization. Since the speed of innovation in security is critical to effective defense, it is no wonder that many organizations are looking for startups.
Unless you are one of the vendor’s largest customers, you will likely not be able to access quality support. It can take weeks for the vendor to respond to a simple question, and many months before they will be able to fix a bug or solve a problem in their product configuration that impacts customer workflow.
Since the products have been around for many years, they are often ridden with technical debt. To make the simplest change or to build a new feature that extends the existing functionality, it can take the company many weeks or months of planning and untangling the complexity before its software engineers can start writing code.
Legacy platforms built to address the unique needs of thousands of customers are often unnecessarily complex, hard to navigate, and may require external consultants to implement, enhance, or customize the solution.
Incumbents are greatly incentivized to become platform players and expand the variety of products they are offering. For customers, it often means that they are forced to pay a premium for features and capabilities they are not using, and continuously deal with the sales team looking to upsell more and more add-ons and premium offerings.
While startups are incentivized to offer lower prices in the short term and monetize their offerings later, incumbents are laser-focused on profitability and increasing their profit margins. This means that startups tend to offer solutions that are much more affordable than those offered by the industry leaders. Moreover, large players have the incentive to lock customers and their data in their ecosystem.
Risks of relying on third-party security solutions
When relying on third-party security solutions, be they early-stage startups or large, established vendors, some risks are just natural.
One example of such risk is a risk that the partner will go through a material change that may impact its ability to remain focused and dedicated to its original mission. While it is commonly thought that it’s only stand-alone, early-stage startups that can be acquired by large companies, we have seen plenty of examples that it’s not quite the case. Here are a few of them:
Cisco is acquiring cybersecurity firm Splunk.
Thales acquired Imperva from Thoma Bravo.
KnowBe4, formerly a public company, has been taken private by Vista Equity Partners.
ForgeRock, formerly a public company, has been taken private by Thoma Bravo.
ZeroFox, formerly a public company, agreed to be acquired by Haveli Investments.
Alphabet’s cybersecurity company Chronicle merged into Google’s cloud business.
When the ownership of a company changes, whether or not the customer is going to be affected will largely depend on the type of acquisition. In some cases, the founding team of the startup will continue to execute their original vision within the larger organization, while in others, founders will pass the reins to the new leadership and leave.
Regardless of the company's size or stage, it can still fail. What is different is how a failure looks like. When incumbents fail to innovate, they usually degrade, stop being relevant, and either get acquired or linger around for another decade trying to squeeze as much from the market as they can. Historically, however, we haven’t seen many examples of when a large security vendor would need to shut down. This is different from early-stage startups that, if they are not successful in gaining traction, have no choice but to pivot or dissolve. Regardless of what stage a company is at, how much funding it has attracted from investors, or who the founders are, it can still fail. IronNet, a former public security company founded by former NSA director Keith Alexander, is an example of this.
Lastly, every security solution, regardless of how big its parent company is, possesses a number of security risks. Security tools can fail to detect a threat causing false negatives, mis-identify benign behavior as threats generating a lot of false positives, or even be used as a trojan horse by attackers to get into the customer environments. While early-stage security startups tend to have a substantially weaker security posture, it is the large vendors that are most attractive to bad actors because of the number of customers who are using them. One example of this is the Kaseya ransomware attack of 2021 which ended up impacting about 1,500 businesses.
Buying best-of-breed vs. best-of-suite tools
Advantages and disadvantages of relying on best-of-breed security solutions
Despite the sentiment in the industry that there are “too many” best-of-breed tools, point solutions play an incredibly important role.
When a new attack vector or a problem area emerges, it is the builders of best-of-breed solutions that usually address the new need. Best-of-suite products, or platforms, are built by large companies and therefore they usually wait until the emerging area has been successfully derisked and proven to present a meaningful opportunity.
Best-of-breed security products are focused on solving a single problem, which means they are able to allocate all of their resources to do it really well. This usually results in a better experience, better security coverage, and potentially better security outcomes for customers.
Point solutions are built to be integrated with the organization’s existing security stack, which means they are usually open, interoperable, and friendly towards other vendors.
Best-of-breed tools offer customers exactly what they need, without constantly looking for an opportunity to upsell other, adjacent tools and capabilities.
Because best-of-breed solutions are centered around a single well-defined outcome, they are much more modular and easy to replace. On the other hand, replacing a security platform is a much harder, costly, and risky initiative.
This flexibility and quality come at a cost. Some of the challenges of best-of-breed solutions include:
Since every best-of-breed solution is offered by a different vendor, built in a different way, and conceived with different assumptions in mind, managing a large number of point solutions results in high additional overhead. Security teams need to negotiate separate contracts, integrate all the tools to work together and work around limitations inevitably introduced by these integrations. This can end up becoming quite expensive, both in terms of contract costs and the resources required to make it work.
Best-of-breed tools increase the organization’s attack surface. The more disjoined solutions an organization needs to assemble together, the more likely it is that it will end up with gaps on the edges.
Security teams simply don’t have the time to manage 50-70 or more separate security solutions. The more tools an organization has, the more likely it is that some will end up misconfigured, thus missing to detect or prevent what they were designed to detect or prevent. I have previously discussed the fact that most security breaches could have been prevented by the tools companies are already paying for. Adding more solutions does not necessarily result in better security.
The more security tools an organization has, the more likely it is to mistake purchasing tools for running a security program.
Advantages and disadvantages of relying on best-of-suite security solutions
Unlike best-of-breed solutions, best-of-suite security products enable organizations to reduce the number of tools. By doing so, they are able to:
Reduce complexity and attack surface created by stacking best-of-breed solutions on top of one another.
Consolidate spend and negotiate volume discounts with fewer vendors.
Simplify contracts and vendor relations by reducing the number of companies the security team has to work with.
The benefits of platformization come at a cost. As I explained in one of my previous articles, “... any monolithic platform becomes less secure as it grows in size. People who had an opportunity to work with a large legacy platform, be it SAP, Salesforce, or Workday, know that the bigger the platform, the less efficient it becomes. Moreover,
Large platforms drown in technical debt.
Large platforms have poor support channels.
Large platforms become insanely hard to implement, especially in fields that require customization.
Large platforms are expensive because most customers are paying for a multitude of features they will never use.
Large platforms are expensive because the deeper they become embedded into the customer’s workflows and the more areas they cover, the harder it becomes to switch and the more power the platform vendor has over the buyer.
Last but not least, the larger the platform, the bigger its surface area, and the more vulnerabilities it ends up introducing. To top it off, bad actors find it easier to focus their efforts on poking holes in one single tool which unlocks all doors, thus leading to the situation when the biggest security products may also become the most insecure single failure points.”
A brief note about buy vs. build decisions for security teams
Whenever I hear discussions about building vs. buying security solutions, I can be sure that the people discussing it represent the top 5-10% of the most mature organizations in the industry capable of developing their own tools. The vast majority of security teams do not have the luxury of getting into these debates as they simply don’t have the resources to even consider building something internally.
Before we talk about buy vs. build decisions, it is important to explain a concept of undifferentiated heavy lifting that I think is critical to this discussion. This term was originally introduced in the 2006 article by Jeff Barr titled “We Build Muck, So You Don’t Have To”. In short, undifferentiated heavy lifting is everything that needs to be done for an application to function but that doesn't increase its competitive advantage in the eyes of its customers. The article has many examples of undifferentiated heavy lifting - “server hosting, bandwidth management, contract negotiation, scaling and managing physical growth, dealing with the accumulated complexity of heterogeneous hardware, and coordinating the large teams needed to take care of each of these areas”. While all this work is important, a customer doesn’t really care what the application’s infrastructure looks like, as long as it works quickly and securely.
The concept of undifferentiated heavy lifting has been heavily used in software engineering but it is equally applicable to other business functions such as security.
Security teams should also be looking for ways to avoid undifferentiated heavy lifting and focus on areas where they can add the most value. In other words, if the problem an organization is looking to solve is not unique to the company and has been solved by the existing vendors, it makes sense to buy what’s already available instead of building it in-house. There could be some exceptions such as when the scale the company requires greatly exceeds what can be supported by third-party tools. That said, when security teams evaluate the cost of building a solution in-house, they frequently underestimate the long-term cost of ongoing maintenance and support. Engineers like building, and so they will often find compelling arguments why whatever is available on the market doesn’t fully solve their problems and why they should be building their own solution instead.
The decision to build a product in-house should come with a clear plan to re-evaluate the situation once a viable alternative becomes available on the market. Security teams often don’t want to give up the tools they’ve developed even though buying the same capabilities from a startup can save significant resources over the long term, and free them up to solve more important problems. Moreover, given that every security team has to operate with limited resources, it is rarely smart to compete with vendors who are fully focused on solving a single problem and who can allocate a large amount of resources to hire armies of threat researchers, detection engineers, and other engineering-focused security practitioners.
Instead of seeking to leverage every opportunity to build tools internally from scratch, security teams would greatly benefit by shifting their focus on:
Building an in-depth understanding of their company’s operations, crown jewels, and risks it could be facing.
Configuring commercial tooling to their environment. As I have previously discussed, most attacks could have likely been prevented by the tools companies are already paying for.
Building custom detection and response coverage fully tailored to their organization, beyond what can be provided by generic off-the-shelf solutions.
Closing thoughts: making decisions under uncertainty
Making decisions about cybersecurity tooling is hard as every decision comes at a cost. Although there can be no one-size-fits-all advice about what to do, some ideas are worth keeping in mind as security teams evaluate their options and assess their pros and cons:
When a new attack vector emerges, there is usually no choice but to buy best-of-breed solutions from startups. As the problem area matures and becomes better understood, platform players will likely either introduce their offerings or acquire and integrate best-of-breed startups into their best-of-suite platforms.
As the market area becomes commoditized and reaches the point when there is no noticeable difference between different options (think of antivirus solutions today), it makes sense to choose the most cost-effective option offered by a platform player.
If a certain attack vector is critical for the company then it makes sense to keep the best-of-breed solution even if a cheaper but more generic option is available.
When there is no solution to the company’s problem on the market, or if the available options cannot satisfy the necessary scale, it may make sense to build custom tools internally. However, the decision to build should be seen as temporary from day one: as soon as an alternative emerges on the market, and as soon as it is sufficiently good (even if it’s not as good as the in-house solution just yet), it is worth exploring switching to what’s available on the market. A company dedicated to solving a single problem is likely to outpace the small in-house team of engineers and quickly build a superior solution. Moreover, by becoming an early adopter of such a solution, the security team gets an opportunity to help shape its direction in a way that solves its own problems better than any alternatives.
I have previously explained that we need not less but more startups. In cybersecurity, startups have been and will continue to act as innovation labs for new approaches, ideas, and kinds of solutions. As long as new attack vectors and new threats continue to emerge, there will continue to be security practitioners willing to dedicate their lives to building defenses.
Security teams need to be smart about the way they make buying decisions and recognize that while more isn’t always better, neither is the full consolidation of all security tooling with one vendor. The answer to the question “What should we be doing?” is fully dependent on the unique needs of a specific company, and what makes perfect sense in one case, could be a disastrous decision in another.
Great insights Ross . I would also add that organisations need to be open to exploring startups by doing POCs and also share their existing problems with startups to look for innovative solutions. Such interactions are more in evolved markets and mature companies but can benefit smaller companies
One aspect which is crucial is also effective support from startups in regional markets. If a large company does not have dedicated customer support in a country it is always better to go with a startup or a regional player who can provide effective support and ensure effective utilisation of the solution.