Security products often do the unthinkable and give the route in because they have not been updated.

You wouldn't expect the products that you rely on to protect your networks to actually expose you to a security compromise, would you?

We're all familiar with the occasional incidents related in the press where an update to a product has killed the system it was supposed to be protecting, but does it get worse than that?

You might be surprised to hear how often during pen testing that we are actually given the route in by the security product.

The irony of a security product creating a security vulnerability!

Sometimes it's as simple as the client failing to include the product in its update process: to run a security product, you're going to have to install it on a box, or buy it ready-to-go on an appliance. If it's a server you built for the purpose of running the security product, then you're probably more aware of the need to keep it patched up to date.

However, if it's a shiny security appliance, sat in a rack somewhere, did you ever consider checking its own security?

Did you assume that the vendor built the OS so securely that it never needed updates?

Have you included it in your update cycle?

Most products will have a facility to automatically update themselves, particularly definition files if they need them. However, core OS updates can be more of a problem. Just because it runs a cut-down or custom, hardened operating system doesn't make it invulnerable.

What about placing security products in highly secured areas of your network? Particularly in PCI card data environments and protectively marked networks, how does the product update its signatures and itself?

It can be problematic letting it connect to the internet, as that could create a vulnerability in itself, but not getting the updates it needs can be just as much of a problem.

Tools that inspect traffic going in to or out of the network are particularly interesting; they will be one of the few systems that you can guarantee will read all traffic. If you have a vulnerability in an IDS, for example, it can be trivial to exploit, as simply sending the traffic into the organisation may result in your exploit being interpreted.

Sounds far-fetched? Not at all – one of the most popular IDS products on the market had exactly this problem a few years ago.

We still come across cases on client networks where this very IDS has been installed, forgotten about, fallen off the radar and hence hasn't been updated – it creates a handy back door into the network for us.

Sometimes security products need to be excluded from scanning by anti-virus software to run properly. That's rather unfortunate, as it gives one a handy location to drop malware and other useful hacking tools into.

We noticed an example of this in a popular 2FA product during a recent client test. It led to a compromise that simply would not have occurred otherwise.

Security vendors are generally very good at getting issues fixed; mitigating a negative PR incident is obviously a strong motivation. However, that isn't much help if you're out of support, aren't aware of the issue, or have simply forgotten about the system – your problem!

We're going to demonstrate this live at the Infosecurity Europe show in April; how a series of security products commonly found on networks could be exploited or taken advantage of to bring about a compromise.

If you haven't done so already, make sure that all of those appliances on your network are covered by your patch process. Check that their engine and operating systems are bang up to date, and keep them that way. Check also any security tools elsewhere on your network, particularly so for freeware and ‘eval' versions, which often get installed and forgotten about.

It only takes one vulnerable security product on your network to bring the whole thing down – and the hacker won't care about the irony.