Last Updated: 2014-10-06 19:55:23 UTC
by Johannes Ullrich (Version: 1)
"Patch as fast as you can" appears to be yet another common security practice leading to network doom. Bricked machines can't be hacked easily, so this may help a bit with "security". But then again, how insecure do you want your machines to be in order to support the latest and greatest patching tools.
Nice story from Lyalc:
"Some years ago, vulnerability scanning a production environment for the first time found about half of the critical production servers in this payment environment had the Windows File protection feature disabled via a registry key."
Ok. This would get me a bit scarred too. Windows File Protection (WFP) is a great feature to keep those Win2k and 2k3 systems a bit more secure, and make hacking them hard enough that some script kiddies may not bother. I like it, and wouldn't want it to be disabled all for sudden.
"Needless to say, incident response processes kicked in very quickly. ?During initial analysis, it was observed that the affected servers had ?patches applied to a critical payment component, several weeks prior to the vulnerability scanning. ?This software, from a global vendor of payment products, is used by a large portion of the payment industry, making it a natural target for malware and rootkit purveyors."
Ok. this would get me excited too (and excitement is never good in security. I like my security operations to be boring...). Payment systems, I think I heard of a couple cases where they got attacked. Yes, they appear to be patched. But what patch? How long were they vulnerable before the patch was applied? And well, defense in depth is for people who can't do incidents response as Lyalc?coninues:
...the site did not have FIM installed, nor had vulnerability scanning been undertaken previously. [FIM: Forefront Identity Manager]
So what happened? How can this possibly be a false positive?
Following this line of investigation identified that the patch package installer was disabling WFP, but neglecting to re-enable the feature, leaving the servers vulnerable to modifications of system files.
Ah! The patch system.?
Just a word about patches, in a week where we just got done with a good number of highly critical emergency patches for shellshock: Stop worrying about speed alone. You will lose. Think about shellshock and heartbleed: You can't possibly patch an enterprise fast enough. What you need instead is:
- a well thought out patching process. How are we patching, how are we avoiding down systems, how do we make sure the patch got actually applied?
- a comprehensive inventory. You can't secure (or patch) what you don't have
- solid controls to detect attacks and exploited systems. You need network visibility to be able to detect attacks and more importantly, exploited systems.