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. |

| Subject: | Re: When is a Security patch not a patch? |
|---|---|
| Date: | Fri, 9 Mar 2007 12:55:27 +0530 |
On 01/03/07 17:22 -0000, solutions@truenorthsatcomm.ca wrote:
Greetings, I have a dilemma. I'm the IT Security dude. I'm responsible for filtering incoming security information (CERT announcements, vendor security patches, real threats, etc.) and doing an impact analysis on them. Since our organization is very structured i.e. ITIL I then send my report to our Service Delivery team who is responsible for the hands on sysadmin. So my dilemma is this. Management is now rethinking this approach (since the Service delivery folks are quite busy) and is expecting me to apply patches. My argument is that; a) No one person can have the detailed knowledge of all the OS's we support (basically all OS's) to be able to do this and; b) That a security patch is just another patch, albeit more urgent than patches applied during the regular patch cycle. To be frank, there is no patch management procedure in place at all. Patches are applied in an adhoc "as needed" basis.
Your sysadmins probably have some kind of version controlled
configuration and system management software in place. (If you don't,
you need to get one in place, see cfengine, bcfg2, Config, Puppet,
radmind, etc).
Then you need a patch management policy. This policy should let you
define patch criticality, and a deployment strategy based on that.
What you are being asked to do is take ownership of the patch management
cycle. What I suggest you do is take ownership of the entire
configuration management system. All changes, including patches will be
rolled out using this management system. Once yuo have this in place,
then the management issue will boil down to who gets access rights to
the version control system in the first place, and who can override what
levels of access.
By doing this, you will also reduce the workload on your operations
people, and make your own life easier. You may want to get in a proper
test suite to test your applications and their required functionality as
well (this is a lot harder). Automating testing and deployment of
patches, upgrades and software will reduce workloads even more and
streamline operations.
Make the patch management policy a part of the configuration management
policy, and you will have a system which runs far more smoothly, with
less human involvement and gives all parties better control.
I am not a big fan of process driven stuff, but I am a fan of process
supported stuff.
Devdas Bhagat
--
"Mach was the greatest intellectual fraud in the last ten years."
"What about X?"
"I said `intellectual'."
;login, 9/1990
| <Prev in Thread] | Current Thread | [Next in Thread> |
|---|---|---|
| ||
| Previous by Date: | RE: System service grapher, Scott Ramsdell |
|---|---|
| Next by Date: | Re: Mutual Authentication scheme, Devdas Bhagat |
| Previous by Thread: | RE: When is a Security patch not a patch?, Justin Nordine |
| Next by Thread: | Re: When is a Security patch not a patch?, klevinson |
| Indexes: | [Date] [Thread] [Top] [All Lists] |