Tuesday, July 3, 2012

Become Flame Retardant: Blend Defense Layers

It surprises me that there is not a greater sense of concern across the security industry, as the ramifications of the Flame malware attack become clearer. This attack strikes at the very tenets of traditional security practices – weaknesses in anti-virus processing, trust chains of certificates, and tardiness in patching. The following ideas were refined during interesting discussions with Bit9, Venafi, and enterprise friends who wish to remain anonymous. By now, most of you have read Mikko Hypponen’s heart-felt emotions on AV being torched by Flame, even though all of the detection signs were there. One of the sustaining worries about targeted attacks such as Flame is the developers are highly certain that the attack will pass under the radar screens of AV researchers because they are not widespread outbreaks, they carry their own communications capability, and they lie dormant for a while so the attack code can penetrate. AV companies detect millions of new attacks per day (!), and must use some automated triage filters to reduce the number of samples passed on to skilled humans. It is unreasonable to expect humans to lay eyes on every single malware sample, but the malware industry designs targeted attacks knowing they will slip through the filters. Organizations with whitelisting products – especially on external-facing servers – report resilience to Flame. You are really missing a key element of a defense-in-depth strategy if you are not using whitelisting. If nothing else, sprinkle whitelisting on various endpoints so you can detect infections and drift out of compliance by comparing machines against the whitelist-established baselines. Certificates form the foundation of identity trust. I call this the circles of paranoia – Something like, “this authority confirms that this person is who they say they are, and this other authority confirms that the first authority can be trusted, and … ah the heck with it – they can’t all be lying can they?” Well, if you have based your trust model on MD5 certificates, then they can be lying. Flame took advantage of MD5 to create a certificate allowing a rogue software update facility to appear as a trusted Microsoft service. There is no network- or host-based scanner that would have detected that malicious communication. IT teams need to ferret out MD5 certificates and especially applications that generate MD5 certs and upgrade those to the latest SHA recommended standards. Assume even the internal-facing applications are at risk. In fact, Flame provides great incentive to re-examine certificate management policies with an eye to shortening cert lifecycles – making any hash-collision operation less attractive. Finally, and I seem to say this with every new attack, the best course of action is to close vulnerabilities with timely patching. It has been more than a decade since I collaborated with Qualys on the Laws of Vulnerabilities, and it seems that the half-life of a vulnerability curve is resistant to flattening (meaning the time to patch systems isn’t improving much). Patch technology has vastly improved – check out Lumension or eEye to complement Microsoft’s Windows Update Services. And if modifying a production application is unappealing, then Virtual Patching from Trend Micro may be the answer for you, or heck periodically replace whole images with updated copies via application virtualization from people like Citrix and VMware. The bottom line is that committed attackers will always be able to defeat AV scanners, so finding other approaches to closing vulnerabilities or blocking attack execution is now pragmatic. Refreshing images and certificates is also worth investigating.

1 comment:

  1. This also got picked up by Information Week and Softmedia! Check 'em out: