Ethical Hacking

Learn to find vulnerabilities before the bad guys do! Gain real world hands on hacking experience in our state of the art hacking lab. Course designed and taught by expert instructors with years of penetration testing experience. 12 student maximum in every class. Certification attempt included in every package.
Computer Forensics Training at InfoSec Institute

Gain the in-demand skills of a certified computer examiner, learn to recover trace data left behind by fraud, theft, and cybercrime perpetrators. Discover the source of computer crime and abuse at your organization so that it never happens again. All of our class sizes are guaranteed to be 12 students or less to facilitate one-on-one interaction with one of our expert instructors.




Network Security Focus-Microsoft
[Top] [All Lists]

Re: Patch Management on Critical Servers (Healthcare)

Subject: Re: Patch Management on Critical Servers (Healthcare)
Date: Mon, 08 May 2006 10:47:32 -0400
-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

beinm@ummhc.org wrote:

I'm just curious to hear how people in the field have been handling patch 
management with critical servers. Have you setup maintenance windows? If, so 
how did you manage the down time? What have people been doing if the device 
or server has an approved FDA configuration? Are you using thing like WSUS?




Matthew,

I work for IBM's GSD and I support two hospitals in Manhattan and for
*nix servers patch management is handled at two levels. One: we have a
change management process where all changes have to be presented at a
meeting and approved, especially patching.

Patching is done through a series of automated scripts that pick from a
library of patches based on what is applicable to the environment and
the software installed on the system.

At another layer patching is first done on non-critical and development
systems prior to being applied to the production environment so any
issues with the patching can be caught and dealt with either by not
applying the patch at all in production (for instance bad patches from
Sun) or working with the applicable vendor to resolve the issues.

Once a battery of patching is slated for application to the production
environment the requisite change records are opened and presented at the
change meetings for the hospitals and dates set.

At both hospitals critical production systems have "mated pairs" of
servers.  While these are not strictly speaking clusters or HA pairs for
logical purposes they can be considered so.  Because we have this we can
schedule the patching so that only one half of a pair are affected at a
time. In other words we will patch one of the servers in a pair one day
wait a day or two and patch the other.  This gives us additional
insurance from "bad patches" in that for a couple of historical cases we
have found issues with patches that didn't show up in our development
testing but did "under load."

As far as FDA affected systems go, we haven't had to deal with that
under the *nix environment yet but we'll cross that bridge if we ever
come to it.



- --
::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::::
Peter L. Berghold                                     Peter@Berghold.Net
"Those who fail to learn from history are condemned to repeat it."
AIM: redcowdawg        Yahoo IM: blue_cowdawg              ICQ: 11455958
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.6 (GNU/Linux)
Comment: Using GnuPG with Red Hat - http://enigmail.mozdev.org

iD8DBQFEX1oDUM9/01RIhaARAv5gAJ9uwsT8bgp3X56h80uzMNrxDqFNOwCglCZR
2a2A3orfSiuhu4KjGI8IY+g=
=/GtE
-----END PGP SIGNATURE-----

---------------------------------------------------------------------------
---------------------------------------------------------------------------
<Prev in Thread] Current Thread [Next in Thread>