4 ms·

Similar to this, I didn't patch my OS X laptop for something like three months because the darn update was a firmware update. It said something along the lines

Similar to this, I didn't patch my OS X laptop for something like three months because the darn update was a firmware update. It said something along the lines of "Make sure your laptop doesn't lose power, and make sure you have a full backup before starting." Uh-huh. I do have a full backup, but clicking that "Later" button was far more valuable than dealing with the 0.001% chance of disaster. And I'm a security guy. If I don't care enough to update every day, what do other people do? (There's not much reason to keep a personal laptop up to date when you're not interesting enough to be targeted and not in the habit of running random internet programs. Or rather, a few months of lag is fine, as long as you're paying attention to what the updates are for.) I think we just don't like to acknowledge the fact that updates sort of suck, yet we bash people and shame them for not doing them. I mean, we don't have many other tools to force them to update, but surprise surprise when people are just concealing the fact that they don't update at all. Even in corporate settings.

wybiral 9y ago
Platforms should maybe get better at differing security patches from other types of updates to help make the choice easier. But, I suppose, at a certain point any sufficiently old setup is simply no longer supported because it becomes too difficult to align the security patches with old versions.
- ethbro 9y ago
  This. It still amazes me that MS hasn't done a better job of this. I'd be interested to hear a heavyweight enterprise sysadmin's take on this, but my experience and read is that it's "toss it at the wall and see what sticks". Which is crazy when MS knows all of the following things: (a) which files the patch changes, (b) how it changes those files, (c) which programs a customer uses, & (d) which MS files get loaded by which customer programs. In days where we can do ISA-to-ISA conversion on the fly, you'd think it wouldn't be rocket science to be able to say "Warning! This patch may effect operation of commonly used programs X, Y, and Z". Or at least have an admin tool to provide that information.
  - SimbaOnSteroids 9y ago
    That sounds sounds like a problem perfect for a startup to tackle.
  - Spooky23 9y ago
    Microsoft does a pretty good job at this, but some patches disrupt certain configuration. The latest round, for example, impacts printing for many people on Windows 7. This is part of what I do. We do a risk assessment -- SMB and Kerberos get patched no matter what, everything else depends on a test cycle and may be deferred for up to 6 mo.
    - pixl97 9y ago
      >Microsoft does a pretty good job at this, but What? With the large monolithic patches that Microsoft has moved to, they have got worse, much worse, recently. It does make it easier to patch everything at once quickly, but if one thing goes wrong, you have to back it off and lose all protections.
      - Spooky23 9y ago
        Unless you were doing external vulnerability assessment, that granularity was a false sense of security. Rolling back sometimes re-introduced old bugs.
        ethbro 9y ago
        Granularity is impractical when applying patches is optional, as it drastically increases the number of applied patch combinations to QA. But my point was more towards MS programatically alerting customers as to what programs and subsystems patches might effect. As far as I've seen, they give you a file list, some brief notes on what the patch is for, and assurance that they internally QA'd it. But I can't see why there's any technical reason that my system can't warn me that an MS library called into frequently by a particular program I use every day is modified in this patch. Which is something I care about almost as much as "MS QA passed this patch" (side note: thanks so much to all the unloved, unknown internal QA folks out there, keeping things from breaking!).

wybiral 9y ago

Platforms should maybe get better at differing security patches from other types of updates to help make the choice easier. But, I suppose, at a certain point any sufficiently old setup is simply no longer supported because it becomes too difficult to align the security patches with old versions.

ethbro 9y ago
This. It still amazes me that MS hasn't done a better job of this. I'd be interested to hear a heavyweight enterprise sysadmin's take on this, but my experience and read is that it's "toss it at the wall and see what sticks". Which is crazy when MS knows all of the following things: (a) which files the patch changes, (b) how it changes those files, (c) which programs a customer uses, & (d) which MS files get loaded by which customer programs. In days where we can do ISA-to-ISA conversion on the fly, you'd think it wouldn't be rocket science to be able to say "Warning! This patch may effect operation of commonly used programs X, Y, and Z". Or at least have an admin tool to provide that information.
- SimbaOnSteroids 9y ago
  That sounds sounds like a problem perfect for a startup to tackle.
- Spooky23 9y ago
  Microsoft does a pretty good job at this, but some patches disrupt certain configuration. The latest round, for example, impacts printing for many people on Windows 7. This is part of what I do. We do a risk assessment -- SMB and Kerberos get patched no matter what, everything else depends on a test cycle and may be deferred for up to 6 mo.
  - pixl97 9y ago
    >Microsoft does a pretty good job at this, but What? With the large monolithic patches that Microsoft has moved to, they have got worse, much worse, recently. It does make it easier to patch everything at once quickly, but if one thing goes wrong, you have to back it off and lose all protections.
    - Spooky23 9y ago
      Unless you were doing external vulnerability assessment, that granularity was a false sense of security. Rolling back sometimes re-introduced old bugs.
      - ethbro 9y ago
        Granularity is impractical when applying patches is optional, as it drastically increases the number of applied patch combinations to QA. But my point was more towards MS programatically alerting customers as to what programs and subsystems patches might effect. As far as I've seen, they give you a file list, some brief notes on what the patch is for, and assurance that they internally QA'd it. But I can't see why there's any technical reason that my system can't warn me that an MS library called into frequently by a particular program I use every day is modified in this patch. Which is something I care about almost as much as "MS QA passed this patch" (side note: thanks so much to all the unloved, unknown internal QA folks out there, keeping things from breaking!).