Time To Patch, Patch Significance, & Types of Cloud Computing
Recently, a quote from Qualys CTO Wolfgang Kandek struck me kind of weird when I was reading Chris Hoff yet again push our hot buttons on cloud definitions and the concepts of information security survivability. Wolfgang says (and IIRC, this was presented at Jericho in SF a couple of weeks ago, too):
In five years, the average time taken by companies to patch vulnerabilities had decreased by only one day, from 60 days to 59 days, at a time when the number of flaws and the speed at which they are being exploited has accelerated from weeks to, in some cases, days. During the same period, the number of IP scanned on an anonymous basis by the company from its customer base had increased from 3 million to a statistically significant 80 million, with the number of vulnerabilities uncovered rocketing from 3 million to 680 million. Of the latter, 72 million were rated by Qualys as being of ‘critical’ severity.
The bold emphasis added is mine. Because it’s not clear if Wolfgang means the speed at which exploit code arises compared to vuln. disclosure (what Qualys calls “half life”, I believe George Hulme reminds us that “Qualys Half life is the number of days after which the number of vulnerable systems are reduced by 50%.”), or the speed at which those exploits are used against Qualys client networks in a significant manner. The latter being information of enormous value if Qualys were to release a study on it. The former, while informative, needs to be compared to what we actually know to be the case concerning the cause of incidents. So after reading the Qualys presentation and figuring they’re talking about the former, let’s get it on, shall we?
Sample size warnings and regular disclaimers, but recent data suggests that in the case where the initial breach “vector” was an exploit against a patchable vulnerability, a very small amount in representation of the aggregate breach data available, the patch had been around for six mos. to over one year.
So given that information, let’s discuss what Chris and Wolfgang are discussing. Concentrating on Hoff’s Bullets #’s Four and Five:
4. While SaaS providers who do “own the entire stack” are in a better position through consolidated multi-tenancy to transfer the responsibility of patching “their” infrastructure and application(s) on your behalf, it doesn’t really mean they do it any better on an application-by-application basis. If a SaaS provider only has 1-2 apps to manage (with lots of customers) versus an enterprise with hundreds (and lost of customers,) the “quality” measurements as it relates to management of defect (from any perspective) would likely look better were you the competent SaaS vendor mentioned in this article. You can see my point here.
One would hope, along with Qualys, that SaaS providers would be quicker to patch, as we might deduce that SaaS vulnerabilities should be of more significance than an unpatched system within an admittedly porous perimeter. In SaaS you have one centrally located and relatively more exposed code base used by many customers. If we use a little FAIR as a model, FAIR says that the Probability of Threat Action is due at least in part to perceived value by the Threat Agent. So let me ask you to consider the relative value of a SaaS installation vs. one corporate installation of the same computing purpose (like, say, Xero accounting SaaS vs. “internal” accounting packages). Thinking of the situation in this manner, we may deduce that there might be a greater need to “patch more quickly” for a SaaS provider. But this is a risk issue that we can only speculate about – we have to be probabilistic due to the lack of similar models for the distribution of computing resources (i.e., The Cloud Future ™).
Of course this assertion, Patch More Quickly is Best, is complicated by the existing data that suggests that the vast majority of data breaches are not due to unpatched, known vulnerabilities, but rather the use of default credentials, SQL Injection problems that were previously unknown, or misconfigured ACLs.
Regarding Hoff’s bullet Five where he says that the cloud is not just SaaS, but also Platform as a Service (PaaS) and Infrastructure as a Service (IaaS), we could apply the same line of thinking and hazard that PaaS and IaaS aspects of “The Cloud Future ™”, deductively, should suffer the same probable frequency of loss events unless/until we cover the absolute basics of risk issue mitigation, asset and event visibility, and asset variability reduction. In fact, we might speculate that because we’re giving up some control over visibility and variability management – that probable Loss Event Frequency should be greater, than current state, not smaller, as Qualys would have us hope.
SaaS, PaaS, or IaaS – I just can’t see things getting better until we are able to address the basic, fundamental problems of Information Security. Rarely, if ever, does adding more complexity result in greater systematic simplicity.
Actually, it could be a floor wax AND a dessert topping, since the slowness of patching could simply be a correlation with the kinds of organizations that also don’t change their default passwords, misconfigure ACLs, and so on.
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.
@shrdlu
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?
Alex,
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
@Patrick,
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.