May 232017
 

For decades Microsoft laid out a foundation that resulted in people looking at patching as a major burden instead of something that should be done on a regular basis.

The WannaCry ransomware attack and the risks that it poses are nothing new to those of us who work in IT. Sadly, the core reason why WannaCry is causing problems is also nothing new to those who work in IT: people (including corporations) don’t update their PCs.

As someone who has been working in IT for 25 years, I too feel the desire to yell “Patch yo’ sh*t, people!” at the top of my lungs. However, I also know that Microsoft has a decades-old legacy of making patches difficult and time-consuming, requiring reboots for the dumbest of reasons. The result is that people don’t look at updating Windows as a security need but rather as a burden. Microsoft has to take some of the blame for that.

The Windows patching problem

Once of the things that I have always loved about UNIX is that patching is relatively straightforward, at least from a base OS perspective. For the most part, the only time when you need to reboot UNIX or drop it into single-user mode is when the kernel or core functions relating to system startup are updated. Otherwise, the patching procedure is to shut down the particular service that’s being patched then restart it after patching is finished.

Windows, however, has made patching a burden since Windows 95. A long-running joke among Windows users is “You’ve pressed the right mouse button. Please reboot to continue.” Unfortunately, Windows’ dependency, justified or otherwise, on rebooting for the simplest of software installs became the norm for Windows users. Rather than take the more sensible, UNIX-like approach of unloading services after patching and reloading services afterwards, Windows decided that it’s best for everyone involved if you reboot whenever any change to system files occurred and it will finish patching afterwards.

I’m sure that Microsoft apologists will claim that it’s because critical drivers or DLLs could only be updated during startup and that this is a security feature or something along those lines; however, printers and external accessories do not contain critical drivers, yet they always demanded that we reboot, especially if some resident program is supposed to run (rather than simply starting the program). Even now in 2017, iTunes for Windows still tells you to reboot your PC after upgrading, which is absurd yet indicative of what Windows users have come to expect for decades.

Let us also not forget the history of reboots when installing Windows patches or service packs on systems have had not been updated in a while. After all, you couldn’t install newer patches (requiring multiple reboots) without older patches (requiring multiple reboots). Even as recently as a few years ago, a fresh Windows XP install on a respectable multicore PC with a fast hard drive was an overnight affair because of the hundreds of patches to be installed and the numerous reboots that were required.

Of course, particularly slow hard drives could turn a simple set of patches into many minutes or – yes – hours of sitting at a blue screen with Windows slowly incrementing the percentage number of how far it had gotten in the update process. Whether this was truly necessary because of the underlying architecture or not is best left for another discussion; but once Microsoft moved to a more daemon or service method of process management, start-up patching and rebooting for anything other than critical kernel files should have disappeared. Additionally, files should have been staged before the reboot during which the staged files would be into place. Based on the speed (or lack thereof) at which post-reboot patches worked, I would guess that copying staged files was not part of the plan. Rather, the “normal” patching procedure was likely taking place.

Decades of “patching = reboots + extended down time” have made Windows security its own worst enemy. Microsoft has created a strong sense of apathy and even revulsion in its user base by making patching seem to be a major burden instead of an important requirement.

Overly aggressive updates aren’t the answer either

Windows 10, however, took the other extreme. Unfortunately, it will reboot whenever it wants and will put the blame on you by hiding behind “we’ll reboot when you’re not busy”. It doesn’t care what the system is doing at the time or what programs you have opened.

In fairness, updating in Windows 10 has become far more transparent than earlier versions and reboots are few and far between. The aggressive method of patching is arguably the reason why so few Windows 10 systems were affected by WannaCry. According to that same Kapersky analysis, Windows 10 accounts for .03% of victims of WannaCry. The ends, however, do not necessarily justify the means. If anything, the aggressive nature of Windows 10 reboots reaffirms any hatred that people have for Windows updates.

I had a few times when I left an audio recording session open to continue the next day only to find that Windows 10 had rebooted overnight. Fortunately I didn’t lose any data, but Windows 10 gave me no warning either. Another time, my main PC was left running overnight to perform a system backup. When I looked at the backup status the next morning, I had a clean desktop. Windows 10 decided “I’m patching and rebooting, so deal with it”.

I’m not the only one who has had this happen. Social media has plenty of instances where people lost work (including entire databases!) because Windows 10 decided that it was going to patch and reboot. Backups, video rendering, 3D calculations, and other processes that can take hours to finish – and are often left to do their work overnight – were all being abruptly halted.

Almost overnight, Microsoft went from “go ahead and patch if you want to” to “you’re patching now and that’s final!” So even though Windows 10 is doing the right thing, it’s doing it in one of the worst ways imaginable, which also does not help to endear the end user to system updates.

Yes, it’s a simplification of a much bigger problem

Before you start ranting, I am fully aware that the underlying problems to WannaCry’s minimal success are abundant and that most have nothing to do with Microsoft.

I blame people who to refuse to use common sense, such as falling victim to phishing and social engineering attacks without any suspicion of the e-mail they receive or the links that they click. Any personal user who doesn’t know by now to treat everything on the Internet with a healthy dose of skepticism deserves what they get.

I blame companies who don’t implement IT security best practices, such as those who put unpatched systems on the Internet with no firewall or those with wide-open firewalls. This includes those companies with IT upper management who refuse to get a backbone and force system downtime to do patching and updates. (I’ll wager that those companies that got hit by WannaCry will start updating more often now!) Those companies that demand no down time but don’t put in a responsible high-availability architecture certainly don’t help matters.

And, yes, regardless of how inconvenient updates and reboots might be, I blame the end user who doesn’t keep their PC up to date.

But no matter how you justify or excuse it, the history of Windows updates is full of aggravation and inefficiencies. Because of that, many people have justifiably come to equate Windows updates with excessive down time, reboots, and frustration – enough to consider patching to be a burden or (at best) an afterthought, not a routine.

For that I definitely put the blame on Microsoft.