Good point. Patching quickly could prove to be quite effective within certain risk models that may be time-independent.

The angle on this that is interesting to explore is the Time-to-Patch stats from Qualys vs. data on breach causes.

I wrote you about this idea a few months ago – fromt the Theory of Constraints, and originally from physics:

Inherent simplicity – the more complex the system, the fewer places you have to touch it to influence it.

It works both ways – good and bad influence – maybe patching/failure to patch is one example of where the idea makes sense.

Patrick

RE: dual purpose – Could be. But we’re talking two pretty different data sets at this point.

RE: SaaS/PaaS/IaaS – I was assuming that (in IaaS, at least), the customer would be responsible for patching the various levels of Cloud Infrastructure (ala Hoff’s diagram in the CSA doc and on his blog) they had “control over”. But more directly to your point – yeah, if we’re doing a “bad job” (for whatever that is worth) patching in a timely manner (and maybe we aren’t) due to political/system fagility, how can we expect a PaaS or IaaS vendor to be any better at it?

There is also a huge difference between a SaaS infrastructure (where you own and control one or two applications as well as the rest of the stack) and PaaS/IaaS, where you are trying to keep your platform compatible with a multitude of applications run by your customers. In the latter case, it’s a struggle to patch at all, since your customers’ applications will be in varying stages of maturity/funding/support.