Re: When is a Security patch not a patch?

[Devdas Bhagat <devdas () dvb homelinux org>]

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