Security Basics: Re: When is a Security patch not a patch?

[klevinson () securityadmin info]

I agree with you that you should have the ability to give input to the process, but owning it entirely seems 
problematic.  There's no guarantee that you can get them to listen to reason, but I would assert that:

* If all these Service Delivery folks can't handle this huge task, why do they think one person will do any better?

* Their proposal would either force the security team to take ownership of non-security patches, or would force two 
different teams to share patching responsibilities on the same systems.  Both of these approaches seem ill-advised.

* What group would be responsible for diagnosing and troubleshooting for when security patches cause problems?  It 
doesn't seem like this should be owned by the security team.  And yet if another team is responsible, they would 
probably not like it if you have the power to affect their systems and their workload without their having any input or 
control.

I'd want them to define what the problem is that they are concerned with, so that you can help find the appropriate 
solution.  It seems to me the root problem might be a lack of automated patch management and/or a lack of commitment of 
staff, time and money.  Assuming this is the case, re-assigning the task wouldn't do much to fix the core problem.

kind regards,
Karl Levinson
http://securityadmin.info