Security has too many tools
We're focused too much on tools and not enough on problems
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.
Another shameless plug for those who missed it! Susan Chiang joined us as CISO, and we’re still hiring. So, if you want to do meaningful security work with a great team and mission, get in touch with me, or apply on our website!
I recently read through the slides of Travis McPeak’s talk “Hard Truths your CISO won’t tell you.” I could probably write (and probably have written) many posts on the “truths” he talks about. Travis is a friend, and we share a lot of similar views as people who have worked in engineering-focused security organizations and observed others. I appreciate that he says what others don’t. You should definitely read through the slides. Whether we want to believe it or not, he lays out the reality of the security industry today and why we struggle to make progress.
Anyway, one of his most-read slides is the following, where he talks about “build vs. buy” decisions.
I’ve talked about this topic from a variety of angles, including why security leaders should invest in security products by buying them rather than actually investing in them, and why I think most security products are bad.
Travis has similar reasons why it’s hard to displace existing products even though they suck, and many times, why people buy products when many times, there’s not a real problem.
I believe that this problem has gotten worse in the past few years as VCs have invested more into security companies, and these companies have spent heavily on marketing. I’ve been hearing the number of CISOs and security leaders say they spent so much time evaluating and procuring tools that they don’t even have time to do any security.
This is a reality. Buying a tool comes with overhead, and the “buy vs. build” decision isn’t that straightforward because maintaining the tool also takes a good amount of effort. However, I digress. The crux of the problem is that tools are too often being viewed as the solution rather than part of the solution. For example, a calculator doesn’t make you better at math or “solve” math problems for you. Another example is that TurboTax solves all your tax problems. Similarly, infrastructure engineers would never say that AWS solves all your problems. Security has fallen into the common fallacy where they see tools as the solution rather than what they are really are — tools to solve a problem.
In security, we’ve forgotten that security like any other organization is there to solve problems and enable other organizations. I talk about how the basic strategy of security isn’t complex and honestly, doesn’t require much tooling.
Security has forgotten its goal
Some say that it was never clear what security’s goals are, and it’s highly dependent. I agree with that. Some organizations view compliance as the primary goal because it enables sales. Others view security as a cost center, similar to legal or finance, which helps reduce risk. More modern, tech organizations can use security as a way to establish trust and differentiate their product. The last one is hard to do because it requires security to be more involved in engineering and actually build rather than just audit/operate.
Although many know that I believe more organizations should use security to establish trust, that’s not the core of the issue. The issue is that security organizations, many times, don’t take actions commensurate with their goals. Going back to the tools example. Compliance-focused organizations, which many security teams are, should spend the minimal amount of money to “check the box,” because compliance doesn’t give credit for doing more. If that’s the case, they should be buying the cheapest tool that solves the problem just enough for them.
Let’s consider if security’s job is risk minimization or prevention of breaches. Then, there’s no reason to buy most products because most of the risk is around phishing or leaked credentials. Below is another graph from Travis’s talk. You’ll likely get breaked by something boring.
If we followed the data, we should be spending more money on protecting credentials, phishing, and app/product security. Of course, this is an oversimplification. The point is that there’s very little reason to invest in complex tools or large security operations centers when the issues are “boring.”
Security is using tools as a shield
I think it’s widely accepted that companies don’t threat model properly. It’s hard, and security has to gain context on the whole application and organization to do this. However, that’s the job of security. As a way to make this easier, security are buying tools, hoping the tool can “save them.” Many tools offer the promise of expertise and context that security teams sometimes lack. The problem is that in order for these tools to make sense as a product for the company creating them, they have to design a generic enough tool. This means that there’s some customization and context that you have to put in yourself. Back to the calculator analogy. The calculator is very useful at doing some complex operations that would otherwise take the human a long time to do, but it still requires you to put in the math logic.
Similarly, software and programming can help do complex operations, but it still requires developers to put in the business logic. The problem is that security now spends so much time shopping for tools whereas they should instead be focusing on going deeper to understand and learn the problem. Then, they should figure out the solution. Only now should they go look for a tool that might help facilitate their solution rather than viewing the tool as the solution that works after you “plug it in.”
Many security teams are likely overestimating the value of a security tool, and as a result, they are overpaying for it. A good example is CSPM where the tool doesn’t actually provide intelligence. It just provides some calls to APIs and scans that are easy for an engineer to build given appropriate time and resources. That’s how companies like Wiz are doing it.
A new way to think about tooling and “buy vs. build”
I think the increased amount of tools available is not the real issue. The real issue is that it’s combined with increased use and complexity of technology at companies. Traditional security teams, which are more IT-focused, have trouble keeping up with these changes. As I talked about above, teams sometimes are using security tools as a shield and/or a solution to fill a knowledge or context gap. However, this is an incorrect usage of tools.
The goal of tools should be seen to facilitate solving a problem. If a solution isn’t clear, or if the security team doesn’t understand the problems, they shouldn’t use the tool as a way to fill this gap.
More specifically, I’m proposing fewer tools and more headcount. Having fewer tools will give teams the bandwidth to figure out solutions rather than spending their time managing tools. How do we know whether there’s a good balance? The best way is to figure out how your team is spending their time. If they are spending more time on learning and working with the tooling than actually solving problems, then it’s a sign that your team is too heavily reliant on toolings.
What does this mean for security leaders? It’s ok to have teams that work around a tool. It definitely shouldn’t be central to that team. A leader should ask whether a team can solve a problem without a tool. The point of this question is to have the team figure out a solution, even if it’s heavily manual. That way, the goal of the tool is to make the team more efficient and execute faster. For engineering-focused security teams, that team should only buy tooling if they can build it, but it’s not worth their time. A problem is that if these teams need tools in order to do their job. Honestly, a lot of tools are available for cloud-first companies through their cloud provider, e.g. AWS, where they can build processes to solve problems and then buy a better tool later.
Unfortunately (or maybe fortunately), an unintended consequence is that this might reveal skill gaps on a team. The good news is that I believe many skills are learnable if given time, and eliminating less effective tools can create that time. In fact, it might actually lead to improved output!
In conclusion, security needs to change its relationship with tooling
We have too many tools, and CISOs keep talking about wanting fewer tools. However, I’ve seen no actionable plans to do this, and each year the number of tools keep growing for each organization. I’m hopeful that the push for efficiency in security will lead to consolidation. A good place to start is to do the exercise above to understand whether your organization is using the tool in the correct way. Hopefully, we will see fewer but better tools in the near future.