Quoting H C <keydet89at_private>: > > One thing that irritates me is the notion that "the > > patch has been out for x > > months and companies should be patched." > > I would have to agree. I have conducted assessments > at enough locations to know that simply arbitrary > installing a patch can do more harm than good. And > not all organizations have the staff, technical > know-how, or hardware to test out patches. This is very true. However, it is more true on some systems then others. Solaris patches tend to blindly overwrite config files, removing any customizations you put in (like security changes, for example). Solaris patches install software that wasn't installed, even on rare occassion starts services that were not previously running. Lots of fun... Tru64 avoids most of these issues, but still has problems. Linux RPMS try to avoid these problems, but do so in various inconsistent ways depending on the RPM author and his upgrade theory (config files may be saved as *.rpmsave, or not installed over the old as *.rpmnew, or other variations. You have to check after a new RPM patch to see what if anything it did, or carefully inspect the RPM before installation to see what it will do). But what is worse is windows. At least with an RPM or a Solaris Patch, I can check the patch before installing it and see exactly what it will do (replace files, patch files, move files out of the way, change permissions, etc). It is relatively easy to inspect the patch to see what it will do and how it will do it. Windows patches tend to be binaries that run and perform the patching. AFAIK, I can't tell what they are going to do before hand, and can only install them and then try to determine what they did after the fact. (This may prove my ignorance of windows patches, but I can live with that). As an Unix admin, I routinely check the patch *before* I install it, so I can backup any needed files before hand, and make sure it won't cause my undo problems. As a windows user, I have no clue how to do this, and simply blindly install the patch and hope for the best. > However, I do think that more should be done by > individual organizations to come up with *some* means > of dealing with these issues. Yes, Microsoft has done > quite a bit with their products to make them a > 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? Well, I find things are not so easy in windows. Just because you don't use software doesn't mean it isn't installed. And just because you don't know what it is, doesn't mean it isn't running as a service on your machine. Now, in theory a good sysadmin would know what is running, etc. But sometimes it is difficult in the windows world. Case in point is the Universal Plug and Play discussions. Which services should be disabled. If you disabled them all, then you not only disable the vulnerability but also other services which depend in some way on the non-vulnerable Universal Plug and Play components... So just disabling all the UPnP services can cause other things to break which may cause problems for users... Another case in point is the "I don't run outlook so it doesn't affect me" (say I use Eudora). But I do manage to have window's address book installed (say, to sync/backup my palm pilot). Then a virus/worm gets in from something other than email (floppy, network share, remote exploit, web page, etc) and runs and sends mail out (via its own smtp server) to everyone in my address book. Why didn't I patch this? Well, there are no patches yet, the virus vendors don't yet have a new footprint for the virus, so I'm SOL. Subcomponents can creep in from a variety of sources. Sometimes there is almost no way to stop such things... > Arbitrarily installing every patch that comes out > isn't the answer. But neither is doing nothing. Do > router/firewall ACLs need to be updated? What about > IDS signatures? 100% agreement here. Eric Jon Rostetter The Department of Physics The University of Texas at Austin Austin, Texas 78712-1081 Office: RLM 7.126 Telephone: 512-471-5821 Email: eric.rostetterat_private ---------------------------------------------------------------------------- This list is provided by the SecurityFocus ARIS analyzer service. For more information on this free incident handling, management and tracking system please see: http://aris.securityfocus.com
This archive was generated by hypermail 2b30 : Thu Jan 03 2002 - 12:44:20 PST