Following the 2017 WannaCry attack against big institutions like the NHS or Telefónica did not apply the Microsoft security patches associated with EternalBlue and were forced to deal with a significant impact to their operations.
What's a reasonable patch management strategy to avoid having this kind of exposure and what are some of the more worrisome side-effects applying patches on a frequent basis would have for the infrastructure of a big institution like the NHS?
As with the patches for the vulnerabilities used by the ransomware, there was no negative impact described by Microsoft.
In a utopia, system administrators would be patching systems on a near daily basis. However, in the real world, it is the complete opposite.
Some updates may have to be reviewed, such that they do not negatively impact the productivity of an enterprise. While rare, some institutions consider down time, and the potential loss of work to be very significant.
Systems may not be connected to the network, or may not be connected to a corporate server that instructs for the deployment of certain updates. Laptops are notoriously known for being behind on patches because of their portable and unconnected nature.
Furthermore, some institutions may have patch cycles, such that a patch might be public, but not deployed for a month or more.
There was no valid excuse for the impact of the ransomware, as the patch and notice was public March 17th, but the vulnerabilities were taken advantage of almost 2 months later (May 12th).
You can read the security bulletin by Microsoft here: https://technet.microsoft.com/en-us/library/security/ms17-010.aspx
The answer is easy, apply (security and quality critical) patches as soon as available from the vendor, which implies you only use vendor supported platforms (this might not always easy to check, for example Ubuntu LTS provides security patches only for a very limited subset of packages.
For non-critical updates it depends on if you want to keep up or plan to redo the systems every 3 years anyway.
Sasser has been the gold standard for cautionary tales about patching. It's believed it was reverse engineered from the April monthly patch and released within a week.
That would be April 2004. The concept of automated patch exploit generation (http://bitblaze.cs.berkeley.edu/papers/apeg.pdf) is your worst case scenario for a released weaponized exploit. Wormable exploits on default enabled services have a long history on Windows, and organizations have had 13 years to get their acts together in terms of timely patching.
The time it took to bundle an already weaponized exploit is actually quite long. (roughly 2 months) Even still there's no excuse in many cases.
Microsoft also tests their patches all together (that is, no exceptions to non-optional patches) organizations use WSUS filters (typically) to restrict patching to critical/security patches only. This is another practice that I would highly discourage, this means you're running a set of patches that make your systems uniquely vulnerable to exploit chaining (http://www.informit.com/articles/article.aspx?p=1439194) as well as decreasing the difficulty an attacker has to elevate privileges after they inevitably get on a system.
If I were designing a patching policy, it would be enforced on all endpoints within 72 hours of release (gate logging in to user endpoint devices until you've patched with a login/startup script.) Further, it would be an "all" patch strategy that matches Microsoft's own quality assurance processes so I'm not subject to issues due incomplete patches.
Not directly related, but here is a story that could explain what patches may need to be reviewed before being applied in production environments. I had been working in a medium to large organization that used automated production tasks based on Microsoft Excel, and a large number of machines were involved in that production system. Nothing wrong till there. As we had security aware admins, every machine was running an antivirus, and antivirus signatures were update every day, during the night.
One night, the antivirus signature file contained a false detection that quarantined a DLL required by Microsoft Office... Nothing could be produced during the all morning, and production only restarted in the afternoon because it took less than half an hour to diagnose the problem, but half a day for the support team to restore the DLL on all machines. It could look not very important, but as the products contained weather forecasts, customers were not specialy pleased to not find them at the begining of the work day...
But that is not a reason to not apply a security patch at least on month after it has been made public.
