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?
- 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.
- 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.
- 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.
- 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
- 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: www.linkedin.com/pulse/why-your-security-product-securing-you-vijay-luiz