People don't patch systems and that's all there is to it

May 13, 2017

Recently (ie, today) there has been all sorts of commotion in the news about various organizations getting badly hit by malware that exploits a vulnerability that was patched by Microsoft in MS17-010, a patch that was released March 14th. I'm sure that the usual suspects are out in force pointing their fingers at organizations for not patching. In response to this you might want to read, say, Steve Bellovin on the practical difficulties of patching. I agree with all of this, of course, but I have an additional perspective.

Although one may dress it up in various ways, real computer security ultimately requires understanding what people actually do and don't do. By now we have a huge amount of experience in this area about what happens when updates are released, and so we know absolutely for sure that people often don't apply updates, and the extended version of this, which is people often still stick with things that aren't getting security updates. You can research why this happens and argue about how sensible they are in doing so and what the balance of risks is, but the ground truth is that this is what happens. Much as yelling at people has not magically managed to stop them from falling for phish and malware links in email (for all sorts of good reasons), yelling at people has not persuaded them to universally apply patches (and to update no longer supported systems) and it is not somehow magically going to do so in the future. If your strategy to deal with this is 'yell harder' (or 'threaten people more'), then it is a more or less guaranteed failure on day one.

(If we're lucky, people apply patches and updates sometime, just not right away.)

Since I don't know what the answers are, I will leave corollaries to this blunt fact as an exercise for the reader.

(I'm not throwing stones here, either. I have systems of my own that are out of date or even obsolete (my Linux laptop is 32-bit, and 32-bit Linux Chrome hasn't gotten updates for some years now). Some of the time I don't have any particularly good reason why I haven't updated; it's just that it's too much of a pain and disruption because it requires a reboot.)

PS: I'm pretty sure that forcing updates down people's throats is not the answer, at least not with the disruptive updates that are increasingly the rule. See, for example, people's anger at Microsoft forcing Windows reboots on them due to updates.

Comments on this page:

I think that what most people hate about forced updates are the circumstances: reminders popping up insinuating that you have been derelict; long periods of uselessness as the updates happen; unpredictable reboots.

There are workable solutions to all of these problems, but no single system has put them all together yet.

1. Downloading updates needs to be automatic, but not expensive. Most desktops don't pay by the megabyte, but some do, and most phones do. So the system updates need to understand when they are connected to free or cheap bandwidth, and only use the network then. The Google system for Android does this well but not perfectly.

2. Desktops and phones have long periods of non-interactivity. It's nearly trivial to predict these after watching a few days of use: people sleep. That's when updates should take effect.

3. There are 4 states a machine can be in after updates have been applied.

 a: only packages not in use have been updated, nothing needs to be done
 b: only packages that can freely be restarted need to be restarted, so they are.
 c: there are packages that need to be restarted that are currently running and are not necessarily safe to restart without saving. These are badly designed and should be fixed so that they can be signaled to properly save state and recover perfectly
 d: there are packages that require the system to be rebooted. If there are no state c packages running, pick a period of normal downtime and reboot.

Only if there are state c packages should a human be required to attend the reboot.

4. Finally, reboots can be made much, much faster on virtually all interactive systems. Using an SSD is a big win, but there are many software improvements to be made. A goal of 30 seconds from starting a shutdown process to being ready to login a user is entirely attainable.

By Aneurin Price at 2017-05-13 18:58:22:

there are packages that need to be restarted that are currently running and are not necessarily safe to restart without saving.

The technical term for that is "running software".

These are badly designed and should be fixed so that they can be signaled to properly save state and recover perfectly

Why stop there? May as well cure cancer, end all wars and poverty, and fly off into the sunset on your winged unicorn while you're at it.

Written on 13 May 2017.
« Where bootstrapping Go with a modern version of Go has gotten faster
People don't like changes (in computer stuff) »

Page tools: View Source, View Normal, Add Comment.
Login: Password:
Atom Syndication: Recent Comments.

Last modified: Sat May 13 00:20:10 2017
This dinky wiki is brought to you by the Insane Hackers Guild, Python sub-branch.