mailing list archives
Re: When is a Security patch not a patch?
From: klevinson () securityadmin info
Date: 5 Mar 2007 20:19:31 -0000
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
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.