This story talks about using third-party patches for security flaws instead of waiting for the vendor to put out a patch. Personally, I am dead-set against it (I posted a while back about it, but I am too lazy to go look for it) for the same reasons the security pros in this article are against it.Â
- It can open other avenues of attack, since the bad guy is likely to start studying the thrid-party patch for security holes.Â
- Potential problems caused by the unofficial patch when installing the official vendor patch
- Management headache of uninstalling the unofficial patch
- Possibly causing support problems with the vendor because of unofficial patch
And I am sure there are more issues. One of the main points brought up in the article is that if you have a good defense-in-depth infrastructure, you can maintain good security without the need to install patches right when they come out. One comment struck me:
Using a mitigation strategy like blocking certain ports or shutting certain programs is the better solution. The user may have to go without a feature for a week, but it’s better than taking a risk with a third-party fix that you then have to go and uninstall before installing the real patch.
I couldn’t agree more. And if you have a good IPS vendor with a quick signature turn-around, then you can probably have the ports turned back on or the features back in operation much quicker.
I talked about this on Alan Shimel’s podcast a few weeks back as well. He asked me what Patch Tuesday was like for a security manager like myself, and I besically told him that it was no big deal really. I trusted in the security I had in place. I’m not saying I’m invulnerable. But locking down the infrastructure and paying attention to current threats and responding to them in a timely manner is the key to stop attacks before patches are available.
Vet
