Slashdot Mirror
The Costs of Patching
prestidigital writes "vnunet has a brief but interesting article in which Craig Fiebig, general manager of Microsoft's security business unit, is quoted as saying "In dollar terms, patching is the most expensive security measures and keeping your antivirus descriptions up to date is the least." That seems like an important statement coming from a company who's patches are possibly responsible for 45% of traffic on some networks."
... to realise that it costs more to do things 2, 3, or 4 times then if they had done it right the first time...
And that is costs more to have a new programmer look at and try to modify code that wasn't written by himself/herself...
Amazing reality breakthrough!
We were all warned a long time ago that MS products sucked, remember the Magic 8 Ball said, "Outlook not so good"
This statement is also known as "an ounce of prevention is worth a pound of cure."
evil adrian
The difficult question is whether the costs of patching outweigh the costs of NOT patching. There's a lot to be said for "if it ain't broke, don't fix it" sometimes.
However, with security patches usually you have no choice. The only decision for some security patches is how long do you wait before deploying it. Don't wanna be the first ones to put a bad patch on now, do we?
My motto is: Never give up - unless it's harder than you want it to be.
responsible for 45% of traffic
But spam is responsible for, what was it Taco, 60% of traffic on networks?
I'm at 105% utilization already!
BTW, it's just as costly, if not more, to have to rebuild your linux kernel, SSL, apache webserver, or samba installation when a bug is found there.
Quit pretending that MS has some sort of monopoly on software bugs. "Bad code" is a patentless technique used ubiquitously.
I don't need no instructions to know how to rock!!!!
The software industry has known for years that the later you find a bug the more expensive and messy it is to resolve
Do not try to read the dupe, thats impossible. Instead, only try to realize the truth
What truth?
There is no dupe
If you want security on your boxen it is prevalent to install just the components you need and no more than that. For example, it is safer to have a dedicated firewall/router and a seperate desktop machine for accessing the Internet than to just connect with a 'one-size-fits-all' installation. This goes for Windows as well as for GNU/Linux and/or *BSD. Myself, I have an OpenBSD box connected to my DSL-line and patching is seldom needed (at least compared to other OS'es). This way I can fool around on my (seperate) desktop machine till my hair falls out but it won't get h4x()r3d...
!ERR: Signature not found.
People who say 'they should have patched' do not understand the stress that installing a patch however critical on a few hundred servers, then in many cases rebooting them, can put in a commercial environment.
If MS wouldn't include so much "junk data" to keep their proprietary data secret in patches, they wouldn't be so large. And, if there was a way to do a patch "rollback", then faulty patches wouldn't bring down a system until a new fix-patch was released. (One of the recent MS patches was found to cause some machines to stop booting)
-----------
From Ape to Man: Evolution
I've applied my fair share of patches from MS, but lately I've become really nervous about doing so. I'm always thinking "what kind of DRM will they include in this one?". It's gotten to the point where I will NOT apply patches for anything but server products, and only reluctantly so. Call me paranoid if you wish, but I can't really shake that feeling. Hey MS, great way to promote security - making users reluctant to apply patches...
Black holes are where God divided by zero
You still have to take the machine offline for all practical purposes. You cant upgrade samba or apache in place, without interrupting service.
So who cares if the downtime is for a reboot or a recompile? From the users point of view the machine is inaccessable.
I don't need no instructions to know how to rock!!!!
Wasn't Microsoft supposed to have a system that would patch without rebooting by now? I thought Windows 2000 was supposed to do it. But here we are on XP, and you still have to reboot for nearly all of the critical patches.
Actually, just the act of patching may roughly equal. But UN-patching a system can be done very easily on a *nix based system. How do you UN-patch a Windows based system?
Also, when I rebuild apache, I know what I am affecting. When I install a Windows patch, I cross my fingers.
My beliefs do not require that you agree with them.
I dont think a apt-get update && apt-get upgrade in cron is that hard work.
Yikes. I don't think 'apt-get update && apt-get upgrade' in your crontab is very smart. The probability of breaking something is too high. In fact, that's the message I'm reading between the lines: virus upgrades won't break anything, so they're no problem to automate, but OS/IIS/IE patches pose a much higher probability of risking extended downtime. I don't think the situation is all that different with the Red Hat Network-- look before you leap.
So long, and thanks for all the Phish
(Some patches break some applications) + (Applications being down means lost productivity, sales, possibly data, depending on the app) + (MS apps won't let you roll back the patch, so you can't recover) = Many companies feel the need to test the patches first.
My computer at work doesn't get patched all that often (luckally it's behind multiple firewalls), because Unigraphics is very touchy (according to our support people).
I'm not shy, I'm stalking my prey
Well... before the knee-jerk MS-bashing starts, let's think about it.
If you patch, you have to recompile the component, and possibly re-boot the machine or re-start the application. This is true for Linux too (unless there's a way to fast-swap kernels that I haven't heard about).
If you update, you don't need to re-start anything.
If you patch, you could have to patch just about anything on the system.
If you update, you are working through one application.
Of course, there's nothing to stop an OSS developer from writing something that just sniffs incoming data for known exploits, like a virus scanner does.
Ahhh... but that would slow the system down.
So I think you have to add "better performance" to the pro-patch argument.
But then, there is probably less effort to updating, especially if it's automated. Is there any OSS system with automated patching that people are willing to trust?
Either way, I think it's an interesting discussion. In practice, I patch.
For all intensive purposes, "whom" is no longer a word. That begs the question, "who cares"?
I think there's a big difference between AV definitions and OS patches. AV definitions can be loaded and unloaded dynamically and have minimal effect on uptime. OS patches (in Windows) tend to be all over the place. MS' System Update Server is a good idea for now - in reducing traffic due to patches. However, in most of my environments, the only things we patch regularly are IE and IIS. We typically only patch the OS pre-SP1, but after that we only apply service packs. In addition, we have IP filtering active on every Win2k server (managed via GPO Registry Settings) so we can granularly control port access. As a result, our Win2k servers have uptimes comparable to our Linux servers, with the exception of reboots related to service packs and major software installations.
Sometimes I wish there was the equivalent of Windows Update for Linux.
In essence, there is. Just requires (as always) a little manual setup on your own.
I have one central update box. It runs fmirror every three hours, pulling down the latest Mandrake patches (8.2, 9.0, 9.1) and emails me if there has been a change.
That box has NFS exports (you could use ftp, if you wish, to avoid the NFS problems) to all the other servers.
The other servers have the update box defined as an "update" source in urpmi.
I can then just log on and run:
urpmi.update -a (updates the list of available RPM's on the local server's cache)
urpmi --update --auto-select (installs any updated versions of RPMS, autoselecting any dependencies)
Dead simple. I don't auto-patch for various paranoid reasons, but there's no reason I can't put in the list update automatically too.
Is this as dead simple as using Windows Update? No.
It is, however, simpler than MAKING windows update was for Microsoft, and that's largely the work I've replicated.
-- Argel
I am no Microsoft fan, but even when if you were to write the software "right", you have to remember that,to quote Pressman, software deteriorate. Therefore even a perfect piece of software will need to be patched at some point in the future because the environment around the software will change (new OS, new hardware, unforeseen complication (can you say Y2K ;-)). Can anybody quote one OS that never needs patching ?
Once you have accepted that you will have to patch, then you do it on a regular basis, on your test box first, then you move the "patch bundle" to the prod boxes. The only problem with this method that has come up recently is the time-sensitivity of security patches, if you want to stay safe you can't really afford the slow cycle of waiting for the patch bundle to come out, let it mature, apply in dev, apply in prod. I have no answer to this one, I'd love to hear other's opinion on it.
There are strategies to reduce patches, like the one that is rarelly mentioned and that I like a lot is de Raadt's idea of code audit , once you found a bug, you know that you have made the same error somewhere else and should go through your code to find it and fix it.