DISQUS

In a really well-managed environment, it should not be an either/or decision on doing patches immediately. Instead, some systems can be auto-patched and some patched after testing. With good statistics (!) on incidents caused by patching, we should be able to move from purely doing risk management, to achieving business-related goals, especially improving up-time and reducing costs. For up-time, we want to find the appropriate proportion and type of systems being auto-patched, balancing the down-time caused by patching itself (and maybe unintended restart of running applications), the down-time caused by broken patches needing remediation, versus the likely down-time due to exploitation of vulnerabilities. Similarly for cost reduction, which might result in different proportions.
Can I encourage contributions to Project Quant http://securosis.com/research/project-quant/ which aims to collect good patching metrics?

a) Cos key management still sucks
b) Because the herd of sheep haven't found it yet
c) Still tricky to work out a good business model
d) But see Appgate.com fior someone who is doing it.