For lots of enterprises, security patches are a pain to test, a pain to deploy and frequently frustrating when they require downtime for the inevitable system reboots.
However, security patches are also a significantly important mechanism for protecting your environment against attacks. They really are.
Unfortunately for lots of organisations, this means that they will downgrade the priority and, in some cases, will delay patching for weeks if not months.
This is a mistake.
On the day security patches are announced, it is rarely clear if exploits are out in the wild. The nature of vulnerability research means that lots of the specifics are kept quiet and often different researchers hit upon the same vulnerability at the same time.
The problem is that it isnt JUST the researchers who find vulnerabilities.
So, on the day the security patch is released, we know that there are “white hat” researchers who can exploit the vulnerability but we dont know if there are any (or how many) nasty “black hat” types have also found it. If Metasploit doesnt have a module for the exploit then we sort of guess its not in the wild, but this is just a guess.
From here things get worse. As soon as patches are released, the bad guys will be able to start reverse engineering the code and building exploits. Worryingly this can happen an awful lot faster than most IT managers would ever imagine.
It is realistic to assume that within about 24 hours of a security patch being released, high end hackers will have a way of exploiting the vulnerability. Within 48 – 72 hours more will have it and by the end of the first week, exploits will be available to pretty much any malicious hacker who wants it. It might not yet be a metasploit module, but that just means you are safe from the bottom end script kiddies.
Delaying patches is a massive mistake. Check them, test them and get them into the environment as quickly as possible or make sure you fully understand the risks and have some compensating controls in place.