Friday, July 13, 2012

Recommending ShareFile

This week I gained more experience than I really wanted in using file sharing services. Fortunately, ShareFile by Citrix saved the day for me after a few other approaches did not work at anything more than wasting my time. Thanks to them I was able to get a large file - greater then Gmail's 25Mb size limit - to a client before my deadline!

I was recording the audio track of a Putting Compliance to Work in a Virtualized World webcast for TechTarget on my iPad. The WavePad software generated a 32Mb MP3 file that I then had to deliver to Mr. Parizo (who performed some editting before posting it behind a registration page for TechTarget subscribers). I have to admit that I am a complete klutz when it comes to using new tools - my brain has become finely tuned at always choosing the wrong options and I had a lot of issues with poor user interfaces from other products.

But let's focus on how to do it right. I loved the ShareFile experience. A simple registration page got me started, using the "browse files" button to upload my MP3 was a snap, and the simple shortened link supplied for me was the perfect thing to mail off. Citrix also followed up a personalized note for support if needed and a customized login screen. I shouldn't be surprised based on my GoToMeeting experiences, but the ease of use and the high level of service really sets ShareFile apart. In any event, my client was able to download the MP3 file and we were off and running. I'm guessing the whole process took less than 30 minutes. This is the way cloud apps should be - if you are looking at sharing files without clogging up mailboxes, then check out ShareFile.

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.