This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Why do you even bother patching?

So there are a bunch of reasons people patch their systems.  In fact, there are probably more reasons people patch systems than why they wouldn't. (although there are some valid reasons NOT to patch things IMHO)


So why do you patch your systems?   Seems like a pretty easy question except that the answers can be pretty varied and there is usually a bit of overlap.


Security?  People patch all the time for security.  Unpatched systems are just WAITING to be infected or exploited. No?


Application fixes?  Stuff gets borked. emoticons_wink.png Vendors push out patches continuously to fix things that should have never made it out of beta testing.


Support compliance? If you are having any issue and call support, after pressing 1 for English, you are almost immediately directed to update to the latest hotfixes and patches for the particular product.  'Licensing issues?  Patch and then we'll talk.'  It can be almost comical at times.


Because? Some people just do it because they were told to.

Personally, since I deal primarily with new systems as a consultant, I patch for Application Fixes and Support Compliance.  Keeping your systems secure usually falls under someone else (Namely the client).   I rely on Firewall, Security, even Network guys to keep the Internet baddies out of my projects.

Oh and don't worry if you are silently thinking Because as your reason.  That accounts for about 99% of the time I click Windows Update on my personal laptop.

Carlo

*Reply to this post to earn 50 points and 1 entry to win an iPod Nano

Message was edited by: Carlo Costanzo Don't want to leave a comment? Try the quick poll - http://thwack.solarwinds.com/polls/1081

  • Application fixes are the main reasons that we patch our systems.  Security ranks as the #2 reason, although we have far fewer security concerns as we do concerns about fixing broken areas of the applications that we use.

  • Application fixes are the main reasons that we patch our systems.

    So with Application fixes, do you patch Proactively (Apply any patch that 'Fixes' something) or re-actively (Search out fixes of things users report broken)?

    I know plenty of clients that only do patching re-actively since the act of actually patching applications makes them uneasy (If it ain't broke, don't fix it kinda thing).

    It seems to be such a delicate balancing act between trying to do good and trying not to do harm.

  • Our systems are patched with security fixes only...this is mandated by our security team.  Even servers that sit isolated far from any real risk are patched and those that don't get flagged by our scans.

  • Unless there is a known bug we need to fix I should say.

  • Our systems are patched with security fixes only...this is mandated by our security team.  Even servers that sit isolated far from any real risk are patched and those that don't get flagged by our scans.

    I think Security Patching is by far the easiest politically. emoticons_happy.png   Since it is typically mandated, you really don't have to worry too much about regression or application testing.  Security tends to trump all in those situations.  From a policy standpoint, if there is a security vulnerability, you just patch it and deal with the consequences with very little exception to the rule.  In most all other situations, the patch would need to be evaluated and considered before implementation. 

  • So having seen many customer environments, I can say that the majority of larger companies tend to have some sort of patching mechanism in place.  It seems the most fluid portion of most environments are the user machines.  It seems the vast majority of folks should be patching user machines.

    As for servers, many companies who have machines down a few layers of firewalls tend to not patch critical servers as sometimes this could interfere with the softwares on those machines.  All of these customers I have seen so far do not provide internet access to these machines and have ample security configured around and thus feel they do not need to patch.

    Sohail Bhamani

    Loop1 Systems

    http://www.loop1systems.com

  • As for servers, many companies who have machines down a few layers of firewalls tend to not patch critical servers as sometimes this could interfere with the software on those machines.  All of these customers I have seen so far do not provide internet access to these machines and have ample security configured around and thus feel they do not need to patch.

    I hear a lot about cutting internet access to unpatched machines or in this case, restricting Internet access therefore reducing the need to patch as much.  Local threats shouldn't be overlooked though.  Machines on a network where SOMEONE has internet access are IMHO running the same risk if they are connected or not.  Most malicious programs that take advantage of security holes attack indiscriminately within one's network trying to overpower other machines in it's wake...

  • We have three zones of systems dev/test/prod so they are patched in that order...Test mirrors prod identically so any issues should arise there first.  This limits our risk.

  • I agree.  Its hard to stop the internal threat.  If you owned LEM, you could add to the mitigation of this somewhat by having agents on all workstations and what not, but for many, this is too much to do/afford. 

  • We have three zones of systems dev/test/prod so they are patched in that order...Test mirrors prod identically so any issues should arise there first.  This limits our risk.

    You would hope so. emoticons_wink.png But its great that you have a process in place though.  As a consultant, I have plenty of first hand experience of the horrors in getting users to test ANYTHING.  Dual systems and parallel work environments have as much appeal to them as a marble notebook and pencil sharpener.  I can NEVER get them to accurately test the new systems I try to implement.  I can ONLY IMAGINE the challenges around routine patching and regression testing.  I suspect that for most companies with dev/test/prod, you would really need a catastrophic error immediately after installation in order to catch something.

    There's only so much time in the work day and those bits and bytes aren't slowing down any.