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."
..because one of the many new feature of server 2003 is the ability to update patches auotmatically.
So they will use this 'cost savings' to push the new product. At the launch event, they bagged on there older products pretty damn hard.
It's part of there latest slogan
"do more with less".
personally, I dln't know who this less guy is, or why I would want to do more with him. Ironically I prefer less to more.
The Kruger Dunning explains most post on
RedHat's up2date works pretty well so long as you stick to their RPM releases of the software you want to keep updated.
It works well for me, and all I need to stay on top of are things I build be hand (typically Webserver and its ilk plus kernel), but all my libraries stay nice and fresh.
SPAM
apt-get update
apt-get upgrade
I don't run Debian's precompiled kernels though so I don't know what the patch/release policy on them is, but for all userland things it's better than WU.
You might want to look at Gentoo. They have a bsd style ports system. I run a cron script every night that leaves a text doc in my home dir what needs to be upgraded. Its a very good system.
Whenever deploying new patches OR antivirus DAT files (they cause havok as well) we did a full regression test of the standard desktop image.
Fist a high level person would look at the patch (usually using install shield's application repackager), read the documentation, etc. and look for possible conflicts with the production environment. This took between 2-4 hours per patch x $60/h. The regression test took one lower-level tech about 2 days to do. We'd lump a few patches together so say 1 tech x $40/h (at least, w/ benefits, etc.) x 2 days / 3 patches per test = about $213/patch + eval ($180 per patch) = around $400 per patch to test. Deployment took another hour to write the install script (rarely did we rely on MS's installer alone), 1 hour to document and send to the regional offices and each office probably spent an hour implementing the thing. Total cost around $600 per patch for a 1,000 desktop, 11 office environment.
Now you know.
closed minded is as closed minded does
As the only sys admin in a company of 50 desktops and 4 Win2k Servers I can fully support the notion that patching is expensive...but not for the company...for ME!
Guess who gets to come in the office between 8 and 10pm to apply these patches to live servers...who has to wait if someone decides to work late. Who has to cross his fingers with every patch hoping that nothing else breaks...ME! And the only thing I get out of it is to be able to leave an hour or two early that friday...woot.
Sure some things I can and do install from remote, but almost every patch requires a reboot and you just never know when a Win2k system isn't going to boot properly and require you to drive in at 1am wearing your bath robe.
Apple free since 1990!
apt4rpm works very nicely for RH. It will not auto update kernels (I regard this as a feature) but it will pull them down if you ask specifically.
See my journal, I write things there
Restarting apache (you don't need to go down for the recompile) is faster than a Windows reboot (and less obnoxious) under any circumstances.
Microsoft has a free product out called SUS (see subject) the SUS works in conjunction with the BSA (no, Baseline Security Analyzer) to determin patch levels of 2000/XP clients and servers it then downloads all neccessary patches in a SIS (single instance storage) at the server. In this way every patch on your network is downloaded only once. If you only have four PCs this cuts update traffic by 75%. This is nearly as effective as ISA server but it is FREE. It is not as effective as coding it write the first time LOL but it is a start.
That all depends on what is being patched. Services and applications can be re-started, but DLLs and other files that are in use by the operating system itself need a re-boot because file system protections prevent the file from being overwritten. MS just locks files too much.
US Democracy:The best person for the job (among These pre-selected choices...)
you can't beat a bit of daily patching
:
I've got "cvsup ports-supfile" on a cronjob
Every day I get emailed a list of the applications that have been updated and I can choose when it's worth patching them (they might not be installed - for instance)
to upgrade my *whole* set of port installed software
#portupgrade -ra
& everything stays in regular updated form
I magically keep in step with the mozilla builds
it's great
that's why FreeBSD ain't dying
There are places where the networks are not touching,and there are places where they are-Boeing's Lori Gunter
The basic string copy functions in C and C++ don't keep a value for the maximum length of a string.
(Actually, they don't even keep a value for the current length of a string, it is calculated by scanning the string and looking for the terminating null.)
The buffer safe string libraries are not designed to be a drop-in replacement for the basic string library, because they demand more information about maximum lengths from the code using them.
Lets face it-- if the bugs that cause the critical bugs even make it to beta, there is something wrong because there is a good chance they will get through even with the best testing.
The problem is not the testing or even the coders. The problem is often the application designers/architects who often are thinking "features" when they should be thinking "security."
I suspect that $1 of design is worth $10 of coding, $100 of testing, and $1000 of patching for Microsoft, let alone the poor customers.
LedgerSMB: Open source Accounting/ERP
I agree in theory, but working at a financial services company with significant investment in Unix, specifically Solaris and HP-UX, the perspective is quite a bit different. This is due to the fact that we have literally _thousands_ of third-party and homegrown apps for various financial systems. Some of these have been written by consultants, contractors, other folks who have since moved on, etc. Without doing proper integration testing, you are fscked, because it becomes almost impossible to know what apps you might impact. So basically, everyone is behind the curve in this area. Like the other poster said, I have no love for MS, but every sysadmin must deal with patching whether they like it or not, and accept the fact that they'll almost always be behind the curve.