Preemptive security technologies - they're great, and you can't beat them. Well, that's how it's supposed to work anyway. If only life was so simple.The core idea behind preemptive protection technologies is to detect and stop entire classes of threat from successfully compromising the integrity of a host, network or application. Sales and marketing teams are only too eager to throw around the "preemptive" term - which can lead to rather embarrassing discussions between customers and technical engineers as the two have work out why a particular threat that was supposed to have been stopped, managed to get through the defenses. Its very rarely because the "preemptive" technology failed to to what it was designed to do - and almost exclusively because of nuances in the attack.
For example, there are litterally dozens of technologies out there being touted as "preemptive" protection against drive-by-download attacks. Some of these technologies focus upon detecting the presence of a shellcode payload, with others may hone in on JavaScript obfuscation techniques. However, despite these preemptive detection technologies, there is a growing list of vectors that bypass each technology. For example, drive-by-download attacks that use Flash scripting instead of JavaScript, or embed the shellcode in a different file - rather than within the JavaScript. The net result is customers scratching there heads and looking for answers. The nuances will often escape them - and the vendors R&D team will have a few late nights adding detection capabilities for the new evasion technique or encoding scheme (if they're lucky).
Don't get me wrong, "Preemptive" protection is damned important. You need it a lot more than some just-in-time signature update. But you've also got to realize that the more ground-breaking the "preemptive" protection is, the narrower its focus is in threat mitigation.
Whats more important than "preemptive" protection? In my mind its post-preemptive protection detection - i.e. being able to rapidly detect when all your combination's of "pre" protection didn't quite work, and your network got nailed despite the effort (and resources) you expended. If you focus exclusively on trying to prevent hosts, networks and applications from being compromised, you're going to have a damned hard time detecting when your systems do in fact get p0w3d by some Internet criminals.
This is particular important when you're facing a more organized and motivated opponent - such as those running an APT operation against your organization.
I discussed this in more detail the other day in my Damballa blog - “Preemptive Protection” Isn’t – If You’re Battling APT’s - and cross posted below...
------>
There’s been no shortage of press covering Advanced Persistent Threats (APTs) this week. While there have been plenty of post-hack discussions over the past few years following the big public breaches, this one’s different – there’s almost a kind of relief that this one’s made it out in the open. I can liken it the relief and revelations that followed that first major tobacco manufacturer’s decision to admit that smoking actually probably wasn’t so good for you after all…
Unfortunately, the revelation of several dozen major organizations being the victim of this particular APT example has just about every security vendor on the planet clamoring to extol and position their latest nicotine patch equivalent. Or, perhaps more appropriately, a lock-box to prevent you from reaching for another cigarette.
In the hussle-bussle of vendors claiming “First” or “Preemptive”, there’s a lot of weighted wordage flying about. But if that’s all true, if a particular vendor was “First” in its discovery, why didn’t they stop the threat or protect the currently known victims? Didn’t they understand the significance of what they had already discovered? Did they choose to keep the information to themselves for competitive advantage? I can’t answer those questions – and frankly any answers I’d likely receive in return from these “First” vendors would probably be carefully word-smithed by a gaggle of marketing folks.
What about “Preemptive”? I like that word – it’s important. Having developed and invented many security technologies that fall in to that bucket over the last decade, I can categorically state that “Preemptive” is good. But (and you know there’d be a “but”), it’s not good enough…
Those nicotine patch equivalent vendors are going on about how they could/would/will/have/might preemptively…
- …detect the fact that the user is visiting a URL that’s probably dangerous
- …detect the malicious JavaScript or HTML that delivered the exploit
- …detect the exploit shellcode
- …detect the buffer overflow
- …detect the memory manipulation of the exploit
- …detect the malicious payload
- …detect the malware component
- …detect the malicious behaviors of the compromised application
- …detect the inappropriate behaviors of the compromised host
- …detect the malicious network behaviors
…and by “detecting” the APT, they’d have been able to protect against it (or an aspect of it). But at the end of the day, all those technologies, for one reason or another, failed to protect these organization from being a (very public) victim of the APT.
Why? Because APT’s aren’t like average-Joe malware, botnets, script-kiddies, hackers, fraud artists and cybercriminal attacks. The thing that makes APT attacks different from the other forms of cyber-attack can best be summed up with the mantra “if at first you don’t succeed – try, try and try again.”
The vast majority of Internet attacks – especially mass Internet botnets – are opportunistic attacks. The bad guys have a broad objective in mind along with a number of tools they specialize in and have a ceiling to the amount of effort they’re willing to expend. They will optimize a particular attack vector, select the preferred delivery method, and pound the Internet (and everyone on it) with that toolset until they’re acquired enough victims. So, while many of the attacks may appear to be “targeted” (e.g. Spear Phishing), their objectives are rather limited (e.g. immediate financial fraud), and if they don’t succeed against the currently highlighted target they’ll simply move on to the next.
APT’s don’t follow this model. If a particular attack vector, tool, technology or exploit didn’t (or is unlikely to) work, they switch to another – never changing targets nor focus.
What does that mean in practice? Regardless of the perimeter or host security technology you deploy, and how “preemptive” it is, it isn’t going to stop an APT. Sure, each “preemptive” technology worked just fine – stopping each and every attack vector, malicious payload or strange behavior it was supposed to – but the criminal operators targeting your organization just move on to the next tool or vector until they find one that works. And lets not forget (or kid ourselves), this probing of network defenses and “preemptive” protection doesn’t happen as an overnight barrage of simultaneous attacks from a small cluster of IP addresses tracked down to the Chinese Army. No, this is low and slow stuff spread over many days, weeks or months, routed via a variety of sources and proxies from around the world – or even through your business partners.
So, can all of these nicotine patch sellers protect your organization against APT’s? No, of course not. They can protect against many of the vectors that may be tried and probably identify the particular exploit or malware they end up using, but at the end of the day APT’s will win.
Which brings me to my final point. I don’t care how you got infected or became the latest APT victim – because you will be – so get over it and do something already. If a criminal operations team is willing to spend the time, effort and monies to target your organization, they will win! So, how do you defeat APT’s? Simple, you detect their presence as fast as you possibly can and remediate the victims almost as fast.
OK, so “preemptive” protection is important – but being able to know when that “preemptive” protection has failed is even more important!
FailSafe
Let me put on my Damballa hat for the moment. I’ve been getting a bunch of queries about whether the Damballa FailSafe solution detects the “Google APT thing in the news”. The answer is Yes, and many of the other APT’s that you haven’t heard about (and are unlikely to hear about). You see, from our technology perspective, we don’t care how you became a victim either (you can debate that’s my influence or cynicism leaking through). Lying at the heart of our technology is the ability to identify the suspicious and unauthorised remote control of systems within the enterprise. All this is done at the network level and an APT’s command and control (CnC) is generally no different from a successful mass-Internet botnet, an insider threat or even a remote access trojan hand placed by a criminal operative. The motivations behind a botnet, insider threat and APT may be wildly different – but the CnC communications do not.
It gets a little tougher distinguishing between a brand new targeted botnet, an insider threat or an APT purely from their CnC traffic. But in reality the trick is to identify those threats that have already navigated your layers of corporate defenses and shut them down. Deciding which particular threat was politically/financially/ethics motivated comes afterwards.
Was this “Google APT thing in the news” the first APT to place Google under it’s cross-hairs? No. Is it the only APT targeting Google? No. Will it be the last APT to be targeting Google? No. Will targeted enterprises be able to prevent APT’s from getting in? No. Is it possible to detect when an APT has successfully bypassed all your “preemptive” protection technologies and compromised your systems? Yes.
No comments:
Post a Comment