Hacker News Reader

Comment by acqq | Hacker News Reader

It's a darn good policy if you're the one who is responsible to apply the patches inside of your organisation and you have to test the effect of the patches to the applications running in your company before you actually install them.

Applying the patch a few days later typically doesn't noticeably increase your risks but rolling them out unchecked can make some serious damage.

View on HN

I wanted to say this, but evidently it was pointless given that seemingly 80% the people on this thread have absolutely no understanding of change management whatsoever, or more importantly the problems you might face when customers have your update infrastructure indirectly linked to national grids and industrial automation. Clearly Microsoft should just release Windows as a repo on GitHub and push fixes to master.

I agree with you and mentioned elsewhere in the thread that patch Tuesday was one of the best moves MS made when they started taking security seriously. Enterprises could now schedule change management around the dates far out into the future which leads to a predictable update schedule downstream.

Before, many enterprises rarely patched because the testing involved was a huge pain and it fell outside what they typically planned for.

At a prior company managing firewalls for SMBs that didn't have room for patch management beyond "automatically apply patches", we loved the predictability of Patch Tuesday. Often we would purposefully schedule around it, so if PT did break something, we could point to the schedule and say "nope, we didn't change anything on the box that Tuesday."

Why can't we just have the choice to apply as soon as it's ready?

If you don't want to apply the patches as soon as they're released, then you'd be more than welcome to put them on hold for 4 weeks yourself when it's more convenient.

This time, the "ready" will be the following Tuesday. Google didn't respect this, effectively providing the 0-day to the world.

There are bad guys looking for 0-days out there. If they learn about the vulnerability from the patch, at least the world has the patch before the bad guys do. Now it's the opposite.

Edit: See _wmd's explanation about the technical details of all this in the same level of the answers.

Basically because bindiff (http://www.zynamics.com/bindiff.html ). The moment an updated binary is available, the clock starts ticking towards a vulnerability being reverse engineered from the update. A few years back, there was a huge amount of research in the infosec community whose goal was to automate extraction of these vulnerabilities (yes really - a robot automatically producing 0-day given an updated binary). Symbolic execution trickery aside, this remains a straightforward task for a reverse engineer to manually perform given a set of debug symbols (which Microsoft supply for developers).

Your options become either to release an update the moment it's tested, immediately making vulnerable customers who have a change management policy (usually also the biggest and juiciest targets - fortune 500s including ironically the likes of Google), or delay any release until some coordinated date, giving everyone an equal and predictable opportunity to cope with the exposure, which is how Microsoft do it.

This entire discussion presumes that this bindiff method of discovering the bugs in Windows is the only method available to attackers.

What are the chances that attackers or other agencies already know of these vulnerabilities and are exploiting them?

Microsoft's delays extend the time that the silent attackers have.

There is a thing here.

You apply a dozen different fixes and test. Something breaks badly. You now have a dozen different root causes to check when, if you applied one at a time and tested (or applied one at a time and let your users test it, which is more commonplace than it should - automated testing tools exist for a reason) you'd know what broke.

I'd prefer to have fixes available for rollout as soon as possible and to decide whether I deploy them or not based on my tests. Automatic mandatory deployment could be on a fixed schedule, for those who can't test or don't care much about it.

If you're in a situation where you test the effects of patches before applying them, then if Microsoft releases the security patch early, YOU have the option to wait and apply it on the regular patch day along with any other patches in the normal schedule.

Releasing the patch late (i.e., on patch day) makes that choice for everyone.

With the patch ready before the vulnerability release, there's no 0-day available to the all nefarious guys in the world. Now thanks to Google, there's one. (Edit: See _wmd's explanation about the technical details of this).

It's not that just the big companies are affected now: all users are.

Applying a patch to everyone at the same seems risky (not to mention scaling issues). Can't they stagger the patch, so if there is an issue with it then only some users have an issue instead of everyone.

If it was an important security patch for a bug that hadn't been publicly disclosed, rolling out to a few machines might be as good as disclosing the bug.

I don't think I'm exaggerating when I say that there is no other company in the world that understands the effects of releasing patches as much as Microsoft does.

Large enterprises already have centralized patch management, so they can decide how fast it gets pushed downstream to their users after MS releases the patch.

Reply on news.ycombinator.com