What makes a security product "good"?
Spoiler: It's not how many features it has
Disclaimer: Opinions expressed are solely my own and do not express the views or opinions of my employer or any other entities with which I am affiliated.
A few weeks ago, I wrote about how I believe security tools are too theoretical and how security has too many tools.
A bunch of people have reached out to me telling me they agree and feel like there’s too much tool fatigue. There are too many vendors, and it’s impossible to figure out which is the right one. Someone else told me that although they appreciate my commentary on where a lot of security tools fall short, I don’t talk much about how to fix this problem. This is definitely true of most of my newsletters. I talk about how some companies might fail or succeed, but I never truly discuss how to fix these problems.
It’s not that I’m trying to avoid presenting a solution, but solutions to these problems are hard. Unfortunately, the only real solution for most of these security products is to not exist. That’s the hard reality of the security industry right now — there are more products than problems. I agree that new problems might come up, especially with the increased use of AI, but tools aren’t going to solve these problems. People are going to solve these problems… with the assistance of tools sometimes.
Despite all this, I do think there is room for more 1B+ security companies. The reality is that there are going to be probably only 1 or 2 companies started at this time that will reach that milestone. This means that a vast majority of current security companies will fail, hence there’s not a “fix” for the struggles of most security companies.
As many of you know, Gartner is a big influencer on the “quality” of security products with Magic Quadrant research. Although it does sometimes recommend the right products, it has done a great disservice to the security industry with its methodology, which is primarily based on demos and interviews. These interviews might capture some of the problems faced by security practitioners in different settings, but they lack the nuance and intuition of someone who is actually in a setting. This might have worked in the past when problems were simpler and more homogeneous across the industry. On top of that, organizational dynamics in both security and its partner teams, e.g. engineering, add more to the complexity. The simplification of all this into a quadrant misses the deeper nuances.
Also, more importantly, security companies spend an inordinate amount of time and resources to get on the Magic Quadrant and stay there. Instead, these resources should be spent on product development that actually benefits customers and the community rather than a research firm. This is also why I write this blog! I wanted to provide a practitioner’s firsthand view of security products.
Ok, enough ranting about Gartner (and other similar research firms). Let’s talk about security products. This LinkedIn post, ironically from an analyst (but a security engineer turned analyst!) James Berthoty sums up my feelings about the state of security toolings and its “ranking.”
This type of “ranking” and “research” are forcing security companies to spend product development on creating more features rather than actually features that drive value. Finally, “best” is in the eyes of the beholder. In security, we have lost sight of the purpose of tools, and it’s distorting our views on what determines a good tool.
What is a “good” tool?
Before we answer this question, let’s answer why we need a tool. If we have unlimited people and no need for efficiency and increased productivity, we don’t need a tool. We can just ask everyone to complete a part of a task and be done. However, this is far from reality. We need tools for a number of reasons. One main reason is that people are a limited resource, so tools can help make people more productive so that we can do more with the limited resources.
Now, we determined that tools are necessary. Let’s answer a question more relevant to security tools. Why do we need to buy security tools? If a company has unlimited engineers, they can build all the tools internally, but again, this is unrealistic because engineering effort is limited. On top of that, most security organizations don’t have internal engineering capabilities to build their own tools. This is why I have advocated and will continue to advocate for more engineering capabilities in security, which I believe will have a compounding effect.
Even if the security team has engineering capabilities, building their own tools might not be the best use of their time and resources. Now, take the extreme with big tech companies like Google and Microsoft. They build their own tools for two main reasons. First, at their scale, the economics make sense to build and maintain their own tool. It is almost always cheaper to have your own tooling and infrastructure at scale. Martin Casado makes a good argument for this in his seminal article about the cost of cloud. However, the issue is that there’s a huge upfront cost both in monetary and human capital. Second, their needs are likely more complex and require a lot more customizations or add-ons to current tools. So, it’s actually cheaper and easier for them to build a tool with the functionality they want in-house rather than buying a platform they have no control over.
In other words, at scale, it almost always makes sense to build your own, but the question is what do you do in the meantime to fill the gaps? This is when buying tools matters. Tools help you fill in gaps where you need a solution and capabilities that you either need quickly and/or don’t have the capabilities to build yourself.
This might seem obvious, but I thought it’s worth mentioning to set the stage for what I believe makes a good tool. The main crux of the matter is that a good tool provides great value at a reasonable price. What this means for the individual is that the tool reduces low-value work and allows him/her to focus on higher-value work. For an organization, this means solving a problem using an efficient amount of resources.
Platforms over features
With the framework above, more features don’t necessarily help solve problems better or more efficiently. It can. Having more features might provide more value, but at the same time, it might make the product confusing and actually lead to inefficiency by causing thrash, which decreases the quality and value of the product.
Some features can be useful, but I argue that they tend to only add incremental value. It usually is good for the customer, but it’s hard to charge more for a feature. As a result, companies shouldn’t really be incentivized to add features until they affect the product experience.
How do platforms play into this? There are a few driving factors why platforms make attractive tools.
First, an important insight is that not all problems are of equal importance. This means the value of solving them is different. For example, dealing with email phishing is a lot higher priority than trying to make sure that the cryptography used is quantum-proof. Of course, that’s an extreme example, and the value of solving a specific value relative to others varies by organization. What this means is that organizations don’t need the best solution for every problem. Sometimes, they just want a solution that’s good enough, and it’s diminishing returns to invest in a great solution. Most platforms have great solutions paired with good enough solutions. The great solutions solve important problems while the good enough solutions solve less important problems but are easy to deploy.
Second, there is a cost to maintaining products from multiple vendors (platforms). There’s an administrative overhead for obtaining the tool and maintaining it, e.g. going through contract renewals, etc. As a result, similar to the above, it likely doesn’t make sense to obtain a great tool to solve a less important problem when there’s a good enough tool on an existing platform.
Finally, having a single platform creates a unified product experience for the customer. Especially if it’s a prevalent platform, it’s easier to find people with certain skills, which makes using the tool and consequently solving the problem less resource-intensive. For example, this is why most startups use Python. It’s easier to hire someone who knows how to use Python well versus other languages.
In my opinion, how we should define how “good” a product is in its ability to deliver value to the customer efficiently. Let’s take Cloudflare, a company that I believe has a strong security platform. It has a great CDN and WAF product. Its SWG is pretty good, but good enough that it’s likely not worth it for most customers to go buy Zscaler. This is true also for its CASB and DLP products. However, Cloudflare falls short on email security providing an opening for companies like Abnormal Security and Material Security. Email phishing is important enough that it’s worth buying a separate product. Similarly, the Cloudflare Access product also falls short, and IAM is so core to a company’s security posture that it makes sense to buy another product like Okta.
One last thing worth addressing is the stickiness of a product. At scale, it makes economic sense to build your own solution, and that day inevitably comes. However, the goal of a good product is to delay that day as long as possible. For example, going back to the cloud example. A private cloud does make more economic sense at scale, but the question is when should a company invest in switching from the public cloud to the private cloud. AWS has done a good job with its platform and has continuously worked to increase the switching threshold. Similarly for Cloudflare, it almost doesn’t make sense to host your own WAF unless you’re a fairly large tech company. Even then, if you host your own WAF, you’re choosing to give up on a great product and have a good enough product.
A lot of these ideas apply to SaaS products in general, but I think it’s particularly relevant for security because there’s recently been a flood of products in the market. With such a large number of products trying to solve a small number of problems, it’s easy to get lost on what the point of a tool or product is and how to think about how “good” it is. Of course, this answer is company-dependent, but the goal of a successful company is to build a product that has a market that thinks it’s “good.” That mentality is lost upon most security products, which just focus on features rather than trying to understand the value they bring.