Why do security products fail?

At every security or technology conference, we get to witness the vast collection of security companies who are begging for your time and attention. Each and every one of them claims that they can solve some of your security problems without any official claim as to how effective such products will be for you.

Security procurement is one of the few decisions any person has to make where both the seller and the buyer are equally uninformed as to whether or not there will be true effectiveness. While technology has advanced, security is still dealing with the same problems of the past. This begs the question, why is that security products not necessarily successful?

What is failure?

When I say failure, I mean that these products while addressing some security debt they tend to introduce toil into every organization where they are procured.

With that said, I believe that there are security products out there that not only solve the problems they say they will but also without introducing the amount of toil that most security products do. The products that fall in this category pretty much do the opposite of what I have listed below.

So why do they fail?

I understand that this is an interesting take to make considering that security has a TAM in the billions of dollars. However, I think we can all relate to the challenges that come with introducing security technology into any organization.

To me, the following reasons are why security products, while some may be effective at the security problem, have failed to really gain brand love across the board.

Lack of attention to user experience

One thing that I believe has been completely ignored by most (usually the biggest vendors) products is the cognitive load that they introduce to their users. Perhaps it is the result of a judgement call that dictates that solving security problems is the only priority so they have the luxury to ignore all else — which seems to be the case. When taking a step back and looking at these products from a neutral standpoint, you will see that the user experience is horrible.

What I mean by this is that information isn’t easily accessible or readily available. Not all products have standardized their formats and alignment of information and that these products create the toil that decisions take longer to make given that accessing the information needed to make them requires quite a few navigational actions. In fact, most of the security platforms out there are the result of mergers & acquisitions and their user interfaces looks & feel like the result of that. No standardized APIs (if they even have any), different formatting and placement per product or feature, etc. I bet you can name a few vendors or platforms that are guilty of this.

For security, by security

Every organization has silos. While most of these are solved by culture, there is no denying that most organizations suffer from a significant silo between security and the teams responsible for either building products or maintaining the systems that generate revenue. This is a known fact that every vendor knows, however, very few products actually work on breaking down these silos.

Most security products are built with the security persona in mind that leaves organizations who procure these products in a position where they need to have security teams demand that these products are deployed by other teams when the products lack basic features that the persona who has to deploy or run them would be looking for. A few examples of these are ease of use and deployment (API first products, please?), automation of operations or deployment, or just overall lack of utilization of modern technologies (example auto-scaling for cloud appliances).

Lack of measurable effectiveness

Whether we want to admit it or not, most security products lack the ability to accurately measure their effectiveness. Sure you deploy a posture management product, a firewall, an email security gateway, an EDR, etc. but how can you tell that these products are actually reducing your security debt? At the end of the day these products were brought in to respond to certain risks that you’ve decided your organization is faced with. But other than knowing malware files being blocked, scam emails or emails with viruses being blocked, or configuration issues with your environment therefore reducing your secure posture, how can you tell that your risks are actually being managed? What about the risk of slowing down innovation or burning out your counterpart teams who should be seen as partners?

This one is on us. We think of security products as the more we buy the better. Reason why there is a metric that measures percentage of IT spend that is allocated for security. There is no metric asked by auditors, insurers, or anyone that measures the effectiveness or operability of these security controls. When was the last time a security team has asked their counterparts who have to deploy and live the pain of these products how satisfied are they?

Keys to success

Here are some principles that I believe every security product should consider:

• Time to decision
• Think of all the customer personas
• Use what’s already there

Time to decision

Products must consider the fact that the main reason for why they are used is for their customers to make appropriate security decisions. These decisions are usually not the result of a single person as they are either based on procedures or in collaboration with the owners of the systems that the security product is monitoring or wants to take action on. This means that this collaboration must be enabled by the product itself rather than designing experiences that only emphasizes on the security person.

One key metric that security products need to measure is the time to decision. How many clicks or navigational changes does it require to get the data and act on it? How do you enable other members of the organization to participate in such navigation? The answer isn’t always a ticket.

Think of all the customer personas

Hello developer first security products! Piggy backing on the above, security products must consider all personas that will have some sort of interaction with the product. Whether that’s a direct or indirect action, the product must enable this flow of communication and decision making. This most likely will turn into an integration play, make sure to have integrations with the products that the customer is already using to make these decisions. As a product manager for a security product, you should ask your customers how are operational or system changes decisions made? Who is involved and what is the existing flow for such actions?

That will guarantee that you are not leaving your security team persona on an island by themselves.

Use what is already there

Naturally, most security products are not walking into an organization where no decisions are made. Organizations make system decisions all the time based on what is triggering it. It could be a reliability problem, an upgrade, new systems or features, etc. There is already some sort of observability into what is there and how changes are made. Understand the landscape of what is there and make sure you have enabled communication flows that transcend from your ‘single pane of glass’ to where decisions are actually made. In short, your security product will not become a single pane of glass, in fact, it’ll just be another screen that your customers must look at and this context switching causes significant toil.

In summary

Your security product will not be the one product that rules them all nor will you have Frodo as a customer (and you should not want there to be) to carry the burden of pushing your product into Mordor. Understand the real pains of your customers and how they make decisions. Provide paths into these decision systems so that you can have cross-collaboration between the persona that pays for your product and the personas that have to deal with it.