The Flame malware throws the integrity of patching into question, which creates quite a quandary for those trained to patch early and often. This represents a significant inflection point for security -- or does it?

Mike Rothman, Analyst & President, Securosis

June 24, 2012

4 Min Read

Everyone is talking about how Flame changed the game. The alleged precursor to Stuxnet broke Windows Update by undermining its cryptography in a truly novel way to pretend its installation was a legitimate update from Microsoft. You can check out the specifics of the attack in this great presentation by Alex Sotirov of Trail of Bits.

This is the kind of stuff that happens when guys who build atomic bombs are set loose on computer software.

But how the attackers actually broke Windows Update is beside the point. This not-so-simple attack now puts a critical anchor of your security operations into question. We've all been taught one of the key fundamentals of security is to patch early and often. You probably constantly remind the ops guys that the day after Patch Tuesday is Exploit Wednesday. You read the anecdotes from breach reports showing many successful breaches resulting from attacks on software where patches were already available (sometimes for months). When updates ship from key vendors, you trust them and you apply them. Right?

Even better, Flame was an ingenious attack vector because most of your traditional controls give a pass to patches/updates. Your HIPS and/or endpoint protection sees registry updates, system files, and configuration changes from patching processes, and allows them. That's what patching does, right? Yeah, that's also what malware does. The only difference is you trust updates you get from the trusted software vendor.

What happens when you can't trust the update? The patching emperor no longer has clothes. They were incinerated by the determined attackers with unparalleled resources. Now you start questioning your patching/updating process. And you should be questioning. As if your job wasn't hard enough, now you need to do malware analysis on signed updates from "trusted" vendors? Awesome.

Now to be clear, analyzing patches isn't a radical departure from the patching process Securosis defined a few years back. In that research, Rich Mogull laid out a 10-step process, and one of the steps was to test and approve the patch. Before Flame, that meant making sure it didn't break anything. Now it means you have to also check for malware-like characteristics in updates.

Or not. Let's be realistic that most organizations don't have the resources to keep up with all the patches in the first place. They are underfunded, under-resourced, and don't have the expertise to deal with simple malware available in the hundreds of kits out there (if you know where to look). They spend most of their time cleaning up the mess of frequent malware infections, so even if they were concerned about the undermined trust of a patching process, they don't have the resources to change anything.

On the flip side, organizations that have a detailed and careful updating process likely already do some level of analysis on the updates. These folks are probably the organizations targeted by sophisticated attackers using advanced attacks. They have in-house malware analysis capabilities, and it's just a matter of having those folks analyze the patches (like they do hundreds of other files a week). Sure, this adds another step in the patching process and maybe extends the patching window a few extra days, just to make sure the updates are legit. These organizations also implement workarounds (like IPS rules) to block new patch-oriented attacks until devices can be updated, anyway.

So does Flame really change the game? Not really. Organizations that have the resources now can add another step to their patching processes to protect against an attack vector unlikely to be used by the attackers you need to worry about anyway. In that way, security is like flying in the U.S. The TSA adds a bunch of ineffective controls to stop an attack vector that the bad guys won't use again. Rock on, security theater.

My bottom line is a bit more pragmatic. It's just a reminder that determined attackers will break your stuff. Like with the RSA attack targeting the tokens used by the real targets, nothing is out of bounds. Any controls you use can and will be gamed. And once again, it highlights the need to balance your defenses with extensive monitoring to shorten the window between when the breach happens and when you know it happened.

Mike Rothman is President of Securosis and author of The Pragmatic CSO

About the Author(s)

Mike Rothman

Analyst & President, Securosis

Mike's bold perspectives and irreverent style are invaluable as companies determine effective strategies to grapple with the dynamic security threatscape. Mike specializes in the sexy aspects of security, like protecting networks and endpoints, security management, and compliance. Mike is one of the most sought after speakers and commentators in the security business and brings a deep background in information security. After 20 years in and around security, he's one of the guys who "knows where the bodies are buried" in the space.

Starting his career as a programmer and a networking consultant, Mike joined META Group in 1993 and spearheaded META's initial foray into information security research. Mike left META in 1998 to found SHYM Technology, a pioneer in the PKI software market, and then held VP Marketing roles at CipherTrust and TruSecure - providing experience in marketing, business development, and channel operations for both product and services companies.

After getting fed up with vendor life, he started Security Incite in 2006 to provide the voice of reason in an over-hyped yet underwhelming security industry. After taking a short detour as Senior VP, Strategy and CMO at eIQnetworks to chase shiny objects in security and compliance management, Mike joins Securosis with a rejuvenated cynicism about the state of security and what it takes to survive as a security professional.Mike published "The Pragmatic CSO" in 2007 to introduce technically oriented security professionals to the nuances of what is required to be a senior security professional. He also possesses a very expensive engineering degree in Operations Research and Industrial Engineering from Cornell University. His folks are overjoyed that he uses literally zero percent of his education on a daily basis.

He can be reached at [email protected]. Follow him on Twitter @securityincite

Keep up with the latest cybersecurity threats, newly discovered vulnerabilities, data breach information, and emerging trends. Delivered daily or weekly right to your email inbox.

You May Also Like


More Insights