Most security products are too automated
This is problematic and will lead to most of these products failing
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.
I’ve seen and heard about various security products recently. The market feels very saturated, especially in cloud and application security. What I mean by “saturated” is that there seem to be more products than problems. Some products feel like they are making up problems. Another trend is that the newer products have been focused on improving efficiency by being more turnkey or “working out of the box.” The AI trend is definitely not helping here as there’s a bigger push to increase security automation. I believe this trend has gone too far.
How did we get here?
When companies owned their datacenters, the security team would purchase and maintain the security software and hardware. Although the company would provide updates, the IT and/or security team would manage the software. However, these products would require substantial initial and subsequent configurations as well as customizations to work properly in environments. Many times, doing these would be difficult, so companies would hire consultants or in-house experts. For example, firewalls required substantial effort to configure until Palo Alto Networks came out with their product.
This situation was great for the company providing the product. Having a large number of features and potential customizations heavily benefitted the company. First, they were able to meet customer requirements, which were the primary buying criteria. Second, because of the complexity, customers needed additional services usually from the company itself. Finally, it created a defensive moat, requiring more R&D costs for a competitor to build a similar product.
Eventually, this led to huge software costs because customers were not only paying for the software itself but also the staff and services to configure and maintain it. This was fine and heavily benefitted the security industry when security budgets started increasing. Companies felt exposed given the prevalence of major breaches, especially the companies that are larger targets. As a result, security teams bought expensive software and were able to hire large operational teams, such as analysts, etc., to use and manage the software.
However, the good times are slowly coming to an end as security budgets are plateauing or even decreasing. Over the past decade, companies have been investing more money and resources into security, but it’s not clear that their security posture and risk are improving. Honestly, I believe this is a self-created problem. Many companies have given security a blank check because of FUD, and security teams have taken advantage of this and operated with little to no accountability for measurable progress and results. Especially in a more cost-conscious environment, executive teams are no longer allowing this to continue and demanding more metrics, hence the greater emphasis on security metrics. Security teams can no longer use the excuse that security outcomes are difficult to measure. As a result, like other organizations, they are being forced to become more efficient and do more with less.
The rise of automated products
For some reason, security is a slower adopter of new technological trends and always lags a few years behind. The concept of automation in software to reduce operational costs has been around for a while, and it gained popularity in infrastructure as companies moved infrastructure management from IT to DevOps and engineering. However, security hasn’t had to push this direction because it has enjoyed large budgets with generous staffing resources.
As security becomes affected by the overall push for organizational efficiency, they are looking to cut both software and staff. An interesting status quo in security is that much of the software still requires a team to maintain. Therefore, an easy way to reduce overall software costs is to buy a more turnkey solution that works out of the box with little to no additional staffing resources, especially since people are typically the most expensive operational cost at a company.
This changing trend has led to the rise of more automated products, especially in areas where staffing operational costs have been high, such as products related to SOC, email security, and application security. An important observation is that these products tend to target operational security teams, which are a larger market, than engineering-focused teams.
Automated products are “too” automated
Higher automation security products work well nowadays because most application environments have become more homogeneous with the increased use of the cloud. Unfortunately, cloud providers are also providing not only more customizations but also more products that create new complexity inside the environment.
I believe these security products have become too automated with the desire to work with little to no configuration or customization to show immediate operational efficiency. This is problematic for numerous reasons.
First, as environments become more heterogeneous, it’ll become harder to build an automated product that will work for everyone. Of course, it’s possible to collect data on an environment and configure it appropriately, but that will take time and defeat the purpose of having a product that works out of the box. Also, the company knows its environment the best, so it would be more effective and efficient for them to do their configurations and customizations.
Second, it’s burdensome and expensive for the product to handle the evolving threat landscape of its customers. As many in the security industry know threats evolve, and marketing, many times, are centered around them. But, these threats aren’t materially different from each other, which means that usually, some small changes to the product can solve the evolving threat. With a more automated product, it will require more R&D effort to handle the evolving threat. It also affects customer environments differently. Maybe, the company wants to handle both threats. Do you now have to create a different product? Do you add more customizations and configurations that you have to explain to your customer? It might take us back to where we started with high costs. What is the product vision going forward? Are you creating more features/configurations or products as threats change? In other words, too much automation places too much restriction on the product.
Third, having too much automation doesn’t always work because it prescribes a solution. I believe there are only a few situations where there are universal solutions for security problems. For example, MFA is a good way to combat credential stuffing and account takeovers. However, for others, solutions might differ based on culture and risk appetite. Some companies are okay with taking on some more risk by allowing for local admin access because otherwise, there would be too much friction in the relationship between developers and security to the point that security would lose effectiveness. Having automation prescribes a solution, but sometimes, the solution might need some customization.
Finally, too much automation creates an additional R&D burden. Many of the products make it easy to do certain workflows, such as integrations. However, it places the burden on the product company to figure out how to work with customers who don’t have these common integrations or workflows. Do they allow the flexibility of customers to create their own integrations? Do they build a community around it? Do they just build the integrations themselves and maintain it? It’s tough as many customers might not buy a more automated product because it doesn’t feel like it’s reduced operational or engineering effort for them. After all, they have to figure out a way to create the necessary customizations, which might be more difficult than buying a more “flexible” product.
So what now?
Everything is best in moderation. In the past, there were too many configurations and customizations. Now, many of the new tools don’t have enough. We have to find a balance. This situation reminds me of this blog post by Kelly Shortridge that talks about how cybersecurity isn’t special. Much of her advice is that cybersecurity is a platform engineering function and needs to learn from DevOps and SRE. Some of the advice is apt for these new automated security products.
These tools need to find a sweet spot. The only guiding advice I have is that these products are trying to be the process, but products aren’t the complete solutions to all security problems. That is, you can’t expect to buy a security product, and your security problem goes away. Products are just tools that assist in solving a problem. It’s important to remember they aren’t the process or the solution but just a part of it. Security leaders need to come up with solutions to problems and figure out how tools work within the processes that are created as a result. Having that attitude and communicating it to security companies will help drive more sensible products that will also benefit a greater number of organizations.
Takeaway
Having started as more complicated products, security tools have over-rotated on automation in the name of simplicity, which I believe is bad for the customer and industry due to the lack of customization. These products aren’t the ultimate solution for the call for security efficiency. Rather, we should be focused on solving problems with processes and solutions, using tools as an important component.