Time to End Microsoft's Patch Tuesday?
buzzardsbay writes "Techtarget's resident security curmudgeon, Dennis Fisher, is calling for an end to Microsoft's monthly security patching cycle. Fisher points out that 'a hacker only needs one unpatched system, one little crack in the fence in order to launch a major attack on a given network. The sheer volume of the patches Microsoft releases each month makes it quite difficult for even the most conscientious IT department to get every patch out to all of the affected systems in a reasonable amount of time.'"
Why don't they just release patches as the make them? Is there a specific reason that they hold them all until "patch Tuesday?"
Patch Tuesday - AKA: The day before the zero-day exploits are released.
That's like saying there are too many cracks in a large damn so you might as well give up on trying to patch them.
"There are four boxes to be used in defense of liberty: soap, ballot, jury, and ammo. Please use in that order." -Ed H
So the sheer volume of daily patches would make this better?
Now, MS should take a clue from Apple and have a lot more "rollup" packages than they currently do.
I'm out of my mind right now, but feel free to leave a message.....
How does the existence (or not) of Patch Tuesday change the number of patches deployed on your network?
And why are you relying on MS to keep your network secure?
I'm not a fan of MS, nor am I a network administrator, but if you're running a network large enough for patching to be a big problem, shouldn't you have a PDC or BDC or something like that that runs SUS? Then you can choose which patches get installed to clients, and when, right? Probably an oversimplification, but it helped in management of our M$ boxes at a previous job.
u-bend
Dennis Fisher fails to grok. Patch Day was created because Microsoft was getting hammered by the poor press which resulted from releasing many patches in one month. Patch Day, as much as it sucks, is probably here to stay.
If you mod me down, I shall become more powerful than you could possibly imagine.
Sounds to me like your IT staff doesn't know how to do their job effectively. Many companies and schools with hundreds or thousands of computers are able to stay patched. It might be more prudent to fire your current IT staff and hire some people that are capable enough to apply patches quickly and remotely without trouble.
Ever heard of Microsoft WSUS client? With it you can push out patches to all your MS clients immediately.
My understanding is that they basically did it to allow IT guys to schedule their downtime and patching, instead of having to scramble every time MS releases a patch in the middle of the week. Which is how it used to work, up until 2003 or so.
It sounds like the problem is not that they only come out once a month, but that so many are released that it takes a long time to apply the patches. If they released one patch every day, it would still take a while to patch every system, especially for large companies or companies with tons of computers.
It sounds to me like the only real solution is to make better code so that you do not have to release patches as often. It might just be an inevitability that IT must live with.
Funtime Candy Wow! - my plan for eventually conquering Japan.
I call bullshit on this anecdotal bit of trivia. Is the author of the article actually suggesting that some companies rush to test the new Winblows patches all through the night on Tuesday so that the patches are ready to deploy on Wednesday ? This sounds like a fresh steaming load of bullshit... what places actually force their employees to work ridiculous hours like this just due to an arbitrary vendor schedule! I would not work at such a place, regardless of the amount of free pizza or Redbull available.
My point is that this bit of exaggeration in the article has no basis in fact and should be supported by quotes from someone who actually enforces this policy at their IT department.
I can throw as many stones as I wish; my house is made of transparent aluminum.
I am all for regular patches, whether weekly or daily for that matter.
The majority of home users I hope patch occasionally, which alleviates a fair amount of trojan'able machines. On the corporate side we personally run internal Windows Update Servers where we can auto-schedule approved updates and push them out on a schedule. The whole concern about the corporate side is laughable since most large Windows shops have some form of patch management, (granted my reference is from ten large corporations) whether internal update servers or pushed updates using something else. The bottom line is Microsoft knows they have security problems and they update it on a schedule.
My concern is not the people that have licensed copies of Windows, but the ones that do NOT and are unable to patch their systems. I think a good portion of the machines that are compromised are non-licensed or cracked versions, which is somewhat amusing.
Why would Microsoft keep bootleg copies from being updated seems more logical to make it "non-networkable" instead of "non-updateable"
When the only tool you have is a hammer, every problem looks like a nail
The original reason why "Patch Tuesday" was created was because too many were giving feedback to Microsoft that their patching process was far too disruptive to their enterprise. Before "Patch Tuesday", you could check any particular machine, at any time of day or week, and regardless of its role or usage it may have a patch pestering people that it needs to be applied and the machine rebooted. "Patch Tuesday" essentially is a "work around" to condense all of these patches that could be highly disruptive into a smaller, brief time frame.
The real problem is the patching system Microsoft chose is highly disruptive. Too many still demand user attention even if applied remotely by an administrator. Although less often, too many still require a reboot which is a larger disruption to the user's work. Should Microsoft consider changing how patching is done so that it isn't so "hands on" and pesters the users and administrators to take action? Improve patching to the point where patches can be applied painless from the IT Center and "Patch Whateverday" goes away.
I am the Sys Admin for ensuring that our roughly 1800 desktops and notebooks get updated with the latest updates. Microsoft's strategy is the very least of my concerns. The patches show up on WSUS the Wednesday morning after they are released. I read up on them, noting any "caveats" in the KB articles and inform our help desk if I find anything signficant. Then, I set my approvals and decline any superseded updates. The clients check in and install the updates over night. I am not sure where all this talk about long nights with Red Bull and whatever come into play. If we have mission critical systems, we withold approval for that group for a week or so until we are confident that there are no undisclosed "caveats." Super simple.
I like having a regular schedule for updates. But I wouldn't mind a little more frequency. Why not the first and third tuesday of every month? Sounds reasonable to me.
Now if were only that easy for all the other software vendors out there like Adobe (Acrobat / Flash), Sun (Java), and so on. Where are their enterprise patch management solutions? Why can't I configure my Java clients to check into to one of my servers to automatically apply security updates? Instead I have to spend more money on a 3rd party patch management solution. And I haven't found one yet that is as reliable and simple as WSUS.
What volume is he referring to? Microsoft release seven (7) patches for the month of May. There were a whopping 6 for April. I am the person doing patches for a Fortune 500 company. More or less, ITMU does it for me. The sky is not falling.
Workstation patches roll in enterprises of any size via WSUS or similar. As far as testing of workstations patches go, that's Microsoft's job. You hold the w/s patches for a few days on your WSUS server, wait to see if there are any issues, and if not, let them roll. If we had to test w/s patches on a per patch basis, we wouldn't be able to run the enterprise. If we were patching w/s's outside of a WSUSish service, w/s's wouldn't get patched.
So, WSUS manages the roll-out of patches to workstations, and you can roll 'em one by one, or in bulk, whichever is your druthers.
The server side is obviously a different kettle of fish. We're not an MS shop in terms of our primary directory (although we sync our directory to an AD instance) or file and print services, so rolling to our MS application servers is a not-so-onerous exercise.
[17] Leary, T., White, C., Wood, P. R., Bhabha, W. D., and Wirth, N. Lambda calculus considered harmful. In Proceedings
Except for the fact that Linux also requires patching. Every other day I have a little star on my desktop notifying me of updates to various libraries, applications, and yes the kernel itself. Mac's have patches too. This is not necessarily a Windows vs. , this is about what the best way of releasing patches is. It's an Incremental vs. Bulk release debate. MS chose the bulk method. Is that a good decision? Maybe, maybe not. Regardless of the OS, patching is always required. No piece of software is bulletproof.
"It's not whether you win or lose, it's how drunk you get." -- H. J. Simpson
It allows IT departments to specifically set aside 1 (or more) days a month on a regular schedule to test the updates before rolling them out to the client computers.
Your comment is accurate, and gets to the heart of the problem. The current system minimizes cost, at the expense of security.
The pundit would rather companies get more staff, do rolling testing, etc., whatever it takes - to maximize security.
Now, as a non-user of Microsoft products and a victim of attacks by unpatched machines, some of them corporate, it's clear that the current strategy just shifts the costs off of the companies and onto me. If it just crashed their networks I couldn't care less. But it's more than that.
So I need to side with the proposal - the users need to improve their security. They can do this by having rolling patches from Microsoft or picking a more secure product to use. I don't care how they do it, but they need to stop expecting me to pay for their poor performance.
Unfortunately, liability is poorly defined in this realm, otherwise I could theoretically sue for damages, and their insurance company would make sure they were in good shape or charge them through the roof for being in bad shape.
My God, it's Full of Source!
OUTSIDE_IP=$(dig +short my.ip @outsideip.net)
tm
Support TBI Research: http://www.raisinhope.org
I have to question this statement. I work (in Engineering, not IT) at a large company with over 100,000 employees. I don't know the details, but the IT department has the patching thing down to a science. Like clockwork, we first get an email when Patch Tuesday rolls around telling us that new patches are coming in the next couple of days and they'll require a reboot. Then by Thursday night, every PC is automatically patched and rebooted. If you shut off your PC every night, the patch simply happens next time you boot up (get some coffee while you wait). Otherwise it happens when you're not there, late at night. If you're actually working during that time, you have the option to delay the reboot. All in all, the process is completely seamless.
Granted, I don't know how much testing they do -- or how much they can do in such a short period of time after initial release. We had one patch a few weeks ago (not a Patch Tuesday patch) that apparently hosed the video drivers of some small percentage of deployed PCs, but the fix was rolled out quickly. Thankfully my PC is so goddamn old that it was unaffected. And of course, I still do my real work on the unix side, so a dead PC would only kill my occasional MS Office stuff. Can't say that about most people, though.
Windows Server Update Services is free and it works like a champ. This free tool has enabled every machine on our networks to remain up to date on patches. It usually takes a couple of days for all of our machines to check-in and install the updates due to roaming users. It only requires a few clicks on my part.
I'll admit that it doesn't make testing any easier, but it does give you the ability to block patches until you have tested them for stability.
I usually test patches for a few days against major apps before approving the updates for installation.
If you have a large number of apps that continually break, then the problem is not patch management, it's vendor management.
-ted
I never have anything going on on Tuesdays...
WSUS combined with good AD group policy rules keeps my 60 or so clients happily updated, I rarely have to manually go download and install a patch.
At least with "Windows Update" I can, somewhat, limit the amount of crap going onto my systems.
But a far FAR better solution is Debian's approach. I get TINY patches and ONLY for what is specifically running on my system.
It is so much simpler and easier to test with that approach.
Particularly when compared to things like WinXP's sp2 (with firewall) approach.
The fine point is that you can get away with not patching desktop linux/unix/macos machines for *years* w/o any problems. Only full internet facing servers really need to be up to date on the patches. In contrast, any windows box that can surf the net or receive email is a sitting duck, whether it's behind a firewall or not.
What makes them sitting ducks? Probably a lot of factors. Throwing patches at machines is a coping strategy, not a solution.
They should have a patch hour, it would be every day - just like a happy hour, but without the half price drinks. Um, or the happiness.
ccalam - acoustic versions of new songs.
I actually like this monthly Tuesdays schedule (gets me excited ;)). Once in a while for urgent updates.
I do also notice sometimes the fourth Tuesdays of each month might have other non-critical releases.
Ant(Dude) @ Quality Foraged Links (AQFL.net) & The Ant Farm (antfarm.ma.cx / antfarm.home.dhs.org).
Apple tends to release patches in bulk as well (bundled into a "Security Update"). The only difference between Microsoft's bulk release method and Apple's bulk release method is that Microsoft's is on a schedule.
Absurdity: A statement or belief manifestly inconsistent with one's own opinion. -- Ambrose Bierce
I would liken linux patches to a database app i recently wrote for my company. I work in the automotive industry, and the app was designed to look through a database for a specific set of parameters. Basically it alerted people via email when certain types of vehicles got checked into our inventory. The app was done, it ran smoothly without crashing, but most importantly it ran. That was a couple of weeks ago. Now, i might be driving home from work, or sitting at my desk reading /. and an idea might *POP* into my head for a way to make the app just a SHADE faster, or some very obscure but totally cool other functionality that it could have. THAT is a linux patch, something that maybe isn't completely necessary, but is pretty darn cool, and might protect against an obscure sort of attack.
A windows patch would be something much more critical. IT would have been if i had released my app onto the webserver a couple of days before it was actually ready, then realized that it had some HUGE flaw (red cars crash the system or something crazy), but that i couldn't recall it, because that would involve re-signing up a few thousand people up for alerts...or migrating the data over by hand.
Now pretend that half of these MISSION CRITICAL patches that i release also create other HUGE mission critical problems. Say, i fixed red cars crashing the system by calling them rouge, but now all the old RED cars are still there, now there are TWO of everything....so now if you search through the DB by VIN or something like that....you find two of everything...CRAP!!! BUT OH NO!!! sometimes we actually have the same car checked in twice intentionally!!! SO how do you tell which is whic0h!?!?
SO yes, linux also releases patches all the time, but they are MUCH less critical.
NewslilySocial News. No lolcats allowed.
End patch Tuesday? That's the dumbest fucking idea I've heard since I've been at Microsoft.
In my experience, the whole reason that you have to "test" patches on corporate machines is that the vast majority of the custom-made and "niche" software that many businesses rely on is HORRIBLE. Bug-ridden, non-standard, breaks every rule. Hell, a lot of it is still 16-bit Windows (and even DOS) software with only minor modifications to keep it working under modern OSs. And so, every update causes problems, because it only barely works anyway.
If corporations were better at updating their software (and determining which software to use in the first place), they wouldn't have to be scared of "Patch Tuesday".
It's an Incremental vs. Bulk release debate.
There's of course the option of releasing it both ways and people can click an option in Windows Update which they prefer.
Of course, if you release patches both ways, it leaves the bulk updaters more vulnerable, as hackers would reverse engineer from the earlier release.
So the immediate patches should be only for known exploits already in the wild, and bulk for the rest.
Patching MS products is broken...
/dev/den it is going be much harder to schedule the updates. How this could be fixed, dunno. One thing that comes into my mind is that I never had to reboot my Debian box after applying any updates (except after kernel update). I guess Windows needs to be more modular, so people could swap broken components on the fly. Dunno, apt ftw.
I haven't patched anything from MS since years, but as far as I recall there was always some downtime due to reboots after applying a patch. I think MS had to release patches monthly, else there would be more downtime. Now that the Patch Tuesday goes to
I think the Patch Tuesday is here to stay, at least 'till the end of this year (vista sp1?).
I've had 10% of our company in my office in the last 2 days with that svchost BS. *sigh*
While many of the patches in Linux are just as you say, merely enhancements (many OSS apps seem to be a constant WIP), there are still plenty of patches that are bug fixes. I'm pretty sure that when Mozilla releases a patch for Firefox, they are not adding enhancements, or re-writing the code to be faster (unless the way they wrote it caused serious issues). Most Firefox patches are bug fixes. That's why they change my version from 2.0.0.2 to 2.0.0.3 and not to 2.5 or 3.0. That's why you also call it a patch, and not a full release. Patches are critical and done when absolutely necessary. Adding a spellchecker "cause it totally be cool" is not critical or absolutely necessary, and that's why that stuff is reserved for bigger releases.
"It's not whether you win or lose, it's how drunk you get." -- H. J. Simpson
A bug might have been there for one year, two years, five years. The chance someone will find it by accident in the next two weeks (average delay to release) is rather slim. On the other hand you know the moment the patch is out, hackers will reverse engineer it within a short period of them. That leads to the following conclusions:
1. You have to patch within a short period of release
2. One patch may break any functionality, so you must test all of it
3. If Microsoft releases patches all the time, you must test all the functionality all the time
In 99% of the companies out there, that's just not going to happen. I love getting daily patches, my desktop or home server isn't a critical business machine. I'm mostly interested in avoiding someone hacking it so I have to set it up again, far more than a broken patch. At the very least that leaves the machine in a "known broken" state that hopefully be fixed by another patch, where as a decent virus infection might end in a reinstall. For many a corporate machine down means you're down. Sales lost, salaries roll and nothing gets done. Sometimes data gets stolen but most of the time the cost is downtime - whether it's broken software or infected software. Quite often the solution is the same - rollback to a known good state (after you've figured out how to not get reinfected). Under those conditions I see why they prefer a mad scramble every patch Tuesaday instead of a mad scramble all the time.
Live today, because you never know what tomorrow brings
I imagine thats a part of the problem, I really don't know what percentage of the problem is due to bad cooperate software. I've seen some terrible stuff as well. It sounds strange now, but I'm guessing that may have actually been the fastest( or at least the cheapest) way to do it back when it was done. Microsoft has produced too many ways of doing everything, and doesn't always do a good job maintaining computability for all of those ways.
Well.. maybe. Or Maybe not. But Definitely not sort of.
All this reasoning misses a key point. If Microsoft releases patches on a very frequent basis, IT departments aren't necessarily going to patch their infrastructures (remember we're talking potentially about tens or even hundreds of thousands of nodes) with the same cadence. So in many cases those infrastructures are going to lag behind the current patch level.
But once a patch is made available, it provides an opportunity to reverse engineer the patch to determine what the defect was. This gives hackers the opportunity to devise attacks that leverage the vulnerability.
So you see what happens: if Microsoft releases too frequently it creates a large window of opportunity for infrastructures to remain unpatched and therefore vulnerable to exploits.
Microsoft chose a monthly release strategy as a balance between too often and not often enough. It's not perfect but the alternative is far less desirable.
I have upgraded to wsus 3.0, removed office updates from the server, and installed the hotfix. The problem only seems to happen if your scaning for office fixes also.
For some people rebooting is an unreliable way to execute...
I beg to differ- the reason to test patches is not just for apps but also for the operating system. Case in point I offer the fiasco that came from MS04-016 (I'm pulling from memory here). That patch zombied a lot of machines.
"Nobody shoots anybody in the face unless you're a hit man or a video gamer"- Jack Thompson
You've got my vote, I'd love a four day week once a month! If only we could get rid of "Meeting Monday" and "Wait for the end of the day Friday" too!
As my weather radio keeps reminding me when there is a thunderstorm alert: "... and stay away from windows".
1011 1010 1101 1100 0000 1111 1111 1110 1110
Shavlik's Patch deployment software works real well in that aspect....you can pick individual machines, OU's, IP ranges or any other combination you can think of. Can decide which machines get which patches....you can configure the time of the patch deployment, when the machines will reboot after said patches are installed.....quite a large number of ways of deploying patches...
This is what we use at my place of work, but still takes quite a bit of time tending to a large number of machines, especially waiting on the server engineers to give you permission to proceed, QA testing, etc......
Still..better than having to touch each machine one at a time....
You're messin' with my Zen Thing, man.....
Cancel or Allow?
"Always forgive your enemies; nothing annoys them so much." - Oscar Wilde
If you use wsus you would have nothing to worry about. Why complain? Just set a set time each day and the computers will download the updates themselves. yes it works for the office problems too. Plus its free.
They test patches before we get them and they automate the deployment. You can also push out other software patches and files. It's not a perfect system but it does make life a lot easier than just using MS updates.
This is the way it goes..
Friday: Look at the advanced notification to get an idea of the scale of the patches. Once or twice a year there a none.. yippee!
Wednesday: In the morning we closely analyse the patches to figure out the impact on our organisation. Servers and clients are differently impacted so we look at this to see if we will need to patch servers. Patches are tested on some representative computer systems.
Thursday: raise the inevitable paperwork for any system changes and monitor for any issues.
Friday: Check for issues with the patches and then authorise for client distribution via WSUS.
Saturday: If necessary, patch those servers that are vulnerable. Claim overtime. Yippee.
We know in advance when this is coming up. We can make plans. We ensure that someone always looks at the patches on Wednesday morning and does the analysis. It's a monthly event that we don't miss. This works pretty well.
Sure, sometimes you need to apply an out-of-cycle patch.. these are rare but Microsoft seems to understand that they are needed. If we miss it, then we'll alway pick up on it again later.
Yeah, hardcore sysadmins might like patch and reboot PCs every couple of days or so, but most sysadmins have other things to worry about than constant patching and in my view Microsoft have the balance about right. (One of the few things I like about them!)
Never email donotemail@WeAreSpammers.com
Are the hundreds of SuSE security announcements sitting in my GMail account illusory? There have been nineteen since the beginning of March, some of which cover multiple issues, and which include problems with the kernel, XFree86, even security-related packages like krb5 and gpg...
And they're not necessary trivial issues. Among the multiple security-related bugs in today's update, for instance, include a potential remote exploit, a privilege-escalation exploit, and a somewhat-remote DOS attack.
- CVE-2006-6106: Multiple buffer overflows in the cmtp_recv_interopmsg
function in the Bluetooth driver
(net/bluetooth/cmtp/capi.c) in the Linux kernel allowed
remote attackers to cause a denial of service (crash) and
possibly execute arbitrary code via CAPI messages with a
large value for the length of the (1) manu (manufacturer)
or (2) serial (serial number) field.
- CVE-2006-5753: Unspecified vulnerability in the listxattr system call in
Linux kernel, when a "bad inode" is present, allows local
users to cause a denial of service (data corruption)
and possibly gain privileges.
- CVE-2007-1357: A denial of service problem against the AppleTalk
protocol was fixed. A remote attacker in the same
AppleTalk network segment could cause the machine to
crash if it has AppleTalk protocol loaded.
Only the dead have seen the end of war.
Microsoft itself is fairly insulated from liability issues with their licensing agreements.
A business that knowingly delays deployment of a security-related patch for reasons of convenience, and suffers loss of customer data or other issues that would otherwise have been prevented -- I would not be so certain that the business itself would necessarily be invulnerable to lawsuits from injured third parties.
Only the dead have seen the end of war.
After repeated experiences of the extremely awful "check for updates" software, which would lock out other apps from starting, including the task manager, I switched it from "notify" to "off". Now I'll do it manually on my own, thanks.
It still puts a x-shield icon on the bar, and I can live with that, but if it nags me one more time that the automatic update is switched off, it will find that it can't live with that because I will hunt down that clippy-like code and make it non-executable.One line blog. I hear that they're called Twitters now.
Diversity is key to survival.
Unlike others such as Oracle, Microsoft actually releases truly critical patches ahead of patch Tuesdays. Oracle's monthly (or is it quarterly) releases are totally inflexible, never release patches inbetween, and DBAs are months behind getting these patches in place because of the "sheer volume"...
Check out our infosecurity industry blog: http://securitymusings.com/
>> You seem to imply that fixing software bugs (which is the purpose
>> of patches) is not a solution!
Fixing two bugs this month and eight bugs next month and three bugs the following, and this goes on for years at a time, tells me there are probably *thousands* of undiscovered security holes in the average windows+office install. They are fixing maybe 1% a month, probably less or the same as the rate at which they introduce new bugs. *That* is not a solution, and I'm not implying it, I'M SAYING IT OUT LOUD.
If solaris or macos was that bad, I'm sure microsoft would waste no time issuing press releases to tell us about that. What do we get instead? "Every OS should have UAC!"
That's the best they can do: fix 1% of the bugs per month and pretend like UAC is something other than a poorly implemented rip off of sudo.
Well screw that. I'm typing this on a RHEL 4 box that I update/patch about once a year, if I get around to it. Total number of viruses, spybots, adware toolbars, keyloggers, popups? Zero.
Why can't microsoft be as good as that?
I don't care how often they patch. I JUST WANT THEM TO STOP FRACKING WITH MY DEFAULT BROWSER!!! This is the second month in a row that I have rebooted to be asked by Firefox if I want it to be my default browser. WTF, over?!?!?! It's MY FRACKING COMPUTER!!!!!!!! I know I know, switch to Linux, the point still remains. WTF is with this crap though?
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
Why is that a M$ problem? Why can't your company just have an internal regular patch schedule? Any patch issued in the past 30 days is put on that end of the month test schedule. If the patch is super-critical then you'll have to break your schedule which is what M$ does anyway when a emergency patch is released. I'm not a large company I can keep up with such updates why must I wait because Lardtech, INC. isn't as fast?
Slashdot, home of supporters of free software, free music, and free speech.Except for Moderators that disagree with you.
I work for an IT department for a very large organisation. The worst thing about having all these patches released on the one day is that everything else grinds to a halt while we go through the patches and prepare them for release. Even if we have deadlines on the Thursday (Tuesday is Wednesday here), everything else stops for the patches.
It would make everyone's life here a lot easier if there were a couple of patches a week and we could spread that workload out and continue with other work.
FFS, it doesn't change your default browser. There is a KNOWN bug in Firefox (since version 2.0.0.2) that makes it think it's not the default browser, when it actually is. The fact that it remains the default browser is easily verified by opening a URL or HTML file: it still opens in Firefox.
2 836828.html
For more information, see http://www.zoliblog.com/blog/_archives/2007/3/26/
What's purple and commutes? An Abelian grape.
Well, shit on me. Didn't know that, thought it was the evil Micro$oft. Dern, now I must apologize. NAH!!!!! Thanks for the info.
45 5F E1 04 22 CA 29 C4 93 3F 95 05 2B 79 2A B2
It's not "Patch Tuesday", it's "Exploit Wednesday".
Release your exploit in the wild the day after the second Tuesday of the month, knowing that there will be nothing to stop you for an entire month!
Why start an attack on any other day?
Every other day I have a little star on my desktop notifying me of updates to various libraries, applications, and yes the kernel itself.
..). One patch a month sounds about right.
There's your answer: your distotr (ubuntu?) patches _everything_ you have, from the kernel to your desktop theme (using the same simple mechanism!). No wonder there's a patch every couple of days.
Microsoft only patches your kernel, window manager, web browser, email client and a few apps (min hunter, solitaire
Except there's one bundle of patches a month...
Patching can break applications when:
I'm sure there's other reasons.
In my experience, it doesn't actually happen that often. But when it does--it's a huge frickin' deal to the customer with a down ecommerce or accounting system. Therefore (if you care about uptime), you have to treat your apps with kid gloves and test everything. Fact of life. And as an aside, I'm not sure why the article author thinks this is a Microsoft thing. Many companies try to stick to cycles like this. Some Unix vendors like to do it quarterly. It's a very practical thing to do. Once the number of systems you manage is higher than...ten, you (should be) are immediately looking for ways to automate and reduce workload. Having patches released on a perodic schedule is a very good way to help address this. Microsoft has this schedule because customers insisted on it, not because Microsoft just decided to do so. I was surprised it took so long actually.
You just outlined everything good about patch Tuesday. Those are the reasons that companies asked for it in the first place. However, why does Microsoft wait until Tuesday to patch 0 day exploits too? Hackers wouldn't reverse engineer those patches, because the details are available online in a more clear format.
Write your own Choose Your Own Adventure. http://www.freegameengines.org/gamebook-engine/
Yes you are correct, I am using ubuntu (most of the time) and it is patching everything from the kernel to my instant messenger. This certainly accounts for the frequency. However, my original point is not that Linux needs patching just as often as Windows. My point is that Linux is not some magical "patch-free" operating system as the original poster was trying to imply.
"It's not whether you win or lose, it's how drunk you get." -- H. J. Simpson