On Thu, 03 Jan 2002 08:59:03 PST, H C <keydet89at_private> said: > management and administrative nightmare, but I am also > quite sick of hearing the excuse that organizations > aren't subscribing to the Security Bulletins b/c there > are just too many to deal with. It doesn't take much > more than a few seconds to see if the issue affects > you at all...if you use Eudora, then an OutLook > vulnerability won't be an issue, will it? windowsupdate.microsoft.com got hit with CodeRed because the original Microsoft advisory stated that the vulnerability only affected certain configurations (if you were using the Index Server). The windowsupdate server didn't use that feature, so the patch wasn't installed. Too bad that the vulnerability was more widespread than the advisory originally stated. More than a few people didn't install IIS patches because the vulnerability list said "Windows .. Server", but their 'Windows Professional' system was also vulnerable because when they upgraded, IIS was installed because they had the old Personal Web Server software installed. I may be mis-remembering the details, but I believe there was at least one "Outlook" vulnerability that was actually an IE issue, and *did* also affect those Eudora users who had configured a "use IE to display text/html" option. And in some cases, it *can* be "more than a few seconds to see". I've seen more than a few times when a vulnerability against a Linux program has come out, and some major detective work was required to figure out if RedHat had already incorporated the change. If the vulnerability was created in frobozz-1.4.3, and fixed in frobozz-1.4.5, and RedHat is shipping a frobozz-1.4.2 that incorporates various upstream patches from 1.4.3 through 1.4.6, are you vulnerable or not? Once you have a handle on what systems are *REALLY* affected, then you get to figure out how to deploy the patch. If you're a large site that has several hundred mission-critical servers, or have several thousand desktops to upgrade, this can be a long, involved, and scary business. And if a *second* critical patch comes out during the 2 weeks it takes to download, integrate, test, and deploy the patch on your 300 critical servers, you *really* have a problem. Do you go back to square one, and integrate/test the combo of patches (thus leaving some systems unpatched for the FIRST hole for another week or so), or do you delay deployment of the second patch for another week? How does your answer change if you worry about the patch itself being bad (which has happend), or a *third* critical patch coming out (which has happened)? When your machine room is over a quarter of an acre in size, everything is a lot more complicated (and yes, our machine room is 0.29 acres ;) -- Valdis Kletnieks Operating Systems Analyst Virginia Tech
This archive was generated by hypermail 2b30 : Thu Jan 03 2002 - 12:36:55 PST