Why you should or should not buy a Cyber security product?

“There is no illusion greater than fear.” –?Lao Tzu

?How many times have you had a security OEM presentation starting with?

• The world has seen # ransomware attacks in the last 12 months
• x% IT managers admitted not having the right tools to detect, investigate and respond to security incidents
• N out of Z organizations admitted not being able to respond to ransomware attacks.

The global cyber security market size is expected to grow from an estimated value of USD 173.5 billion in 2022 to USD 266.2 billion by 2027. No wonder, every security OEM is ramping up and trying to sell its products to its potential customers. And for most vendors, selling security is like selling insurance. You can sell insurance to someone when he is scared. The more the scare levels, the more you can sell. It is a different story if the customer needs insurance of that level. A trusted advisor would always try to solve a problem that exists and not play on emotions.?

Here is what I found in my interactions with customers on cybersecurity.

I have seen four major reasons why customers buy security products. First, is to cover the basics, for example, a firewall/ IDS/ IPS protecting the servers. Then there is a group of buyers who follow the herd, where a peer has started to deploy a new security technology like Network Behavioral analytics, or some analyst has started to flood the media with a new buzzword. The third reason is to meet compliance requirements where companies are mandated to have a specific security solution in place like a Network Access Control mechanism for industry-specific compliance reasons mandated by the industry regulator. And finally, and not so trivially in reaction to an incident, when something has gone wrong, and we want to plug a hole. We are so focused on plugging the exploited channel that we forget there could be many more that we need to fix.?

?Most of the time, these reasons for buying security are tactical and are like falling to an insurance salesman’s pitch and giving in to fear.?

?There are times, though rare, when I have come across customers who want to do things proactively, and want to follow a framework.?

Here are some reasons why you should shut the door for a scaremonger, and get a trusted advisor instead.

It helps you start from the basics - Create an inventory of your assets, do a proper risk assessment, identify the existing capabilities, identify gaps, create a plan and take proactive steps to strengthen your security posture.?

You are trying to secure your organisation, and your organisation is unique. The assets you own, the channels you use to transact, and the risk assessment is unique to your organisation. It is too much of a generalisation to replicate what somebody else is doing and hoping it will work for you as well.?

There are 200+ security vendors out there, with overlapping capabilities. Each vendor is trying to sell something without regard to what you already have. Security is a niche area, and you can always find one or two differentiated features in a product from another vendor that you already have. Does it mean you should buy the new product for that additional feature, and pay for the entire functionality that you have already deployed? The real question to be answered is does this additional feature add value to what I already have? Do I need this? Now? Is there an alternative? Having a framework would enable you to answer these objectively.?

Security is all about context, and hence there needs to be an exchange of context among the multiple security products deployed. Security architects and buyers must identify and ascertain how a new product could share context with other deployed systems. Since there is no common industry standard to exchange this context, we rely on a SIEM to correlate information from multiple products and provide some actionable information. Making the SIEM collect all logs/ events would lead to enhancing the SIEM capacity (additional costs). The buyer needs to validate if a new detection system can work and integrate natively with an existing enforcement system. This can help reduce the SIEM load and provide a timely response to events.?

And finally, security is more about people and processes than mere technology. You need to build your organizational structure that aligns with your security goals and ensure that the teams have the right tools and technology to operate in their domain without causing organizational friction.?

All this can be achieved, if you have a big picture in mind in terms of the security functionalities you require, do an assessment of the capabilities you already have, and then plan on building the additional capabilities over time (unless you are not budget constrained).

I would love to hear from you if you already have a framework/ reference architecture, and how is that working for you.?