The horror of the security product presentation

“Attackers can get in within seconds.” “Data can be extracted within minutes.”

If you are in IT (especially if you manage IT), chances are that you have sat through a security product sales presentation. It contains scare stories of vulnerabilities and attackers and tells you about just the product to solve the problem.

It starts with a few recent headlines. There will typically be one about a security breach that lost a company many credit card numbers belonging to its clients. This might be followed by another headline that talks about lost social security numbers or other personal information. (5 minutes)

Step 2 is the scariness of the task of the IT team. There are plenty of vulnerabilities that any IT infrastructure may have. The ante is quickly upped to introduce “zero-day” – vulnerabilities that are only known to the attacker and not even to the vendor who created the security products that are in use. The scares are further escalated to show how quickly data can be extracted and for how long the attackers can remain in your network before they are typically detected. (5 – 10 minutes)

Then comes the question. What can we do about this? The answer immediately follows. “We need something that … does A, B, C and D!” (1 minute, typically just one slide)

The big reveal that we have been waiting for! Introducing PRODUCT!!!  (5 minutes)

An explanation follows as to how A, B, C and D are done by the product. There is an additional explanation as to why no other product compares (20 – 30 minutes).

What is shameful about the aforementioned presentations is the amount of time that they waste in an attempt to scare people into buying a product. Not only that, the security product is presented as the necessary solution that will fix the problems that none of your existing products could fix.

No security product will secure your IT infrastructure by itself. See this previous post that I made for more information. There are plenty of situations where the existing products in one’s infrastructure, effectively used, can provide the level of security that is required by management. A direct question to the salesperson as to the measurable effectiveness of the product will always be met with caution. One would just not expect it, coming so soon after the wonders of the newly introduced product.

Security devices need to keep one-upping each other. So do security sales pitches. Perhaps a good way to improve them would be to not waste the customer’s time and patience attempting to scare them.

Why is your security product not securing you?

You have spent a few hundred thousand dollars on a flashy security product. Why are you not secure?

You have done your due diligence – you stated your security requirements and made a request for tenders. You invited the three best choices to provide proofs of concept. After the POC, you awarded the tender. Now the product has been set up and the vendors are off your premises. You do not feel more secure than before. Why?

  1. Is the product being used for its key security area?
    Firewalls should be used for managing traffic flowing in and out of your network. Data Loss Prevention tools should be used for preventing data loss. Vulnerability scanners should be used for finding and informing you of vulnerabilities. SIEM and other monitoring tools should be used for monitoring.

    There are plenty of good salesmen who give the impression that their product can do everything. It cannot. Product vendors are happy to talk about how their products “integrate” with other products that are already in the customers’ networks. Understand to what extent they integrate before you take this talk seriously – and how much effort it takes to do the integration. Which brings us to the next point.

  2. Is the product configured properly?
    A firewall that contains no rules is a brick. Everyone who knows anything about firewalls knows that they need to have rules stating what traffic is allowed and denied. More complex security devices also need to be configured before they can be used.

    You may have been told about the product’s out-of-the-box features. Everyone loves out-of-the-box features. The customer has it without having to pay more money to the vendor. The vendor talks it up for an easier sale. Are those out-of-the-box features adequate to give you the security that you need? In most cases, they are merely the starting point, i.e. the place where you start fine-tuning from. In some cases, the out-of-the-box features are so useless that you need to start from scratch.

    Make sure that your product is configured to your environment. This might take many man-days of effort and should be part of your project cost considerations. This is such a crucial point that I may make a follow-up post on it.

  3. Do your engineers know how to use it?
    I do not mean the two-hour “handover” that the vendor engineer provided before he left. Have the engineers spent a couple of days (in some cases a week) going through every item in the device’s interface? Or did they take the vendor’s training course?

    Can they generate a report if needed? Do they know what action to take if a vulnerability scan comes up with list of high-priority vulnerabilities? Can they use your SIEM to find the pattern of events that led to a security attack? Can they use your access control software to find out who last accessed a particular folder? Each security device comes with its particular set of questions. If your engineers do not have the answers, you will not be secure.

  4. Do your administrators have the time to manage it?
    Spare a thought for the administrator. All he wants is to be left in peace. He has now been given an additional device to manage. In some cases, he will play dual-role also as the aforementioned engineer who has to use the product.

    The new device(s) must be added to the administrator’s daily checklist. The administrator must be able to notice whether the device is in a healthy or unhealthy state. If it goes down, the administrator must at least know how to get help from vendor support. I once went on-site two months after a project to find that the device had not been running for a month. #Fail

  5. Is there an incident management procedure in place?
    The product is working. It sends you an alert. Someone is attempting unauthorised access. A procedure needs to be in place for your analysts to take action. This will not happen overnight. At the beginning, you will need to start with a set of the most common use cases that you will encounter with the product. This will need to be refined over the years such that the slightest aberration can be discovered within minutes. You are unlikely to have this in place as soon as the product has been implemented at your site.

These are some of the reasons you might not be secure even after setting up a security product at your site. I might be publishing more details on some of the points raised here.

If you think that I missed some of the reasons your security product is not securing you, I welcome your views in the comments.

This essay was original posted at my LinkedIn page: