We (Rich and Gal) were chatting last week about the destructive malware attacks in South Korea. One popular theory is that patch management systems were compromised and used to spread malware to affected targets, which deleted Master Boot Records and started wiping drives (including network connected drives), even on Linux.

There was a lot of justfied hubbub over the source of the attacks, but what really interested us is their nature, and the implications for our defenses.

Think about it for a moment. For at least the past 10 years our security has skewed towards preventing data breaches. Before that, going back to Code Red and Melissa, our security was oriented toward preventing mass destructive attacks. (Before that it was all Orange Book, all the time, and we won’t go there).

Clearly these attacks have different implications. Preventing mass destruction focuses on firewalls (and other networking gear, for segmentation, not that everyone does a great job with it), anti-malware, and patching (yes, we recognize the irony of patch management being the vector). Preventing breaches is about detection, response, encryption, and egress filtering.

The South Korean attack? Targeted destruction.

And it wasn’t the first. We believe Stratfor had a ton of data destroyed. Stuxnet (yes, Stuxnet) was a fire and forget munition. But, for the most part, even Anonymous limits their destructive activities to DDoS and the occasional opportunistic target.

Targeted destruction isn’t a new game but it’s one we haven’t played much. Take Rich’s Data Breach Triangle concept, or Lockheed’s Cyber Kill Chain. You have three components to a successful attack – a way in, a way out, and something to steal. But for targeted destruction all you need is a way in and something to wreck.

Technically, if you use some fire and forget malware (single-use or worm), you don’t even need to interact with anything behind the target’s walls. No one was sitting at a Metasploit console on the other side of the Witty Worm.

So what can we do?

We definitely don’t have all the answers on this one – targeted destructive attacks, especially of the fire and forget variety, are hard as hell to stop. But a few things come to mind.

We cannot rely on response after the malware is triggered, so we need better segregation and containment. Note that we are skipping traditional defense advice because at this point we assume something will get past your perimeter blocking. Rich has started using the term “hypersegregation” to reflect the increasingly granular isolation we can perform, even down to the application level in some cases, without material management overhead increasing (read more).

As you move more into cloud and disk-based backups, you might want to ensure you still keep some offline backups of the really important stuff. We don’t care whether it’s disk or tape, but at some point the really critical stuff needs to be offline somewhere.

Once again, incident response is huge. But in this case you need to emphasize the containment side of response more than investigation. On the upside these attacks are rarely quiet once they trigger. On the downside they can be quite stealthy, even if they ping the outside world for commands.

But there is one point in your favor. Targeted destruction as an endgame is relatively self-limiting. There’s a reason it isn’t the dominant attack type, and while we expect to see more of it moving forward but it isn’t about to be something most of us face on a daily basis. Also, because malware is the main mechanism, all our anti-exploitation work will continue to pay off, making these attacks more and more expensive for attackers.

Well, assuming you get the hell off Windows XP.