Following up on my previous post about the Advanced Persistent Threat, I continue to enjoy the discussions that have emerged from the recent Google/China incident. The past week has seen by far some of the best analysis of APT I have seen in some time.
One line of conversation has been about how APT, specifically the threat component, is not about malware. Specifically, this addresses the positioning around by the antivirus vendors who continue to perfect their defenses around older attack forms - a process I call “Perfecting the Obsolete” – and look to defend market position by framing APT as malware. In Mike Cloppert’s blog he notes in a post about the Google incident that the “defense industrial base has been pleading with the AV industry for innovation to address more sophisticated threats and detection resiliency for at least 5 years, likely longer”. The A/V vendors will continue to characterize APT as malware largely because they have no effective answer, in spite of the wildly inflated claims of their love affair with recently acquired/developed whitelisting tools and prevalence data.
Eventually the dialogue went to the suggestion (Threatpost blog entry by Scott Crawford and Nick Selby) that APT should be called Advanced Persistent Adversary, ideas similarly expressed by an Andy Jaquith blog post and a great post by Richard Betjlich). I have no issue with that line of thinking, because I think the nature of the adversary is what has changed IT security so dramatically, not the attacks themselves. The new adversary is organized, skilled, relentless, opportunistic, and enormously resourceful. They are also patient, willing to invest time in research and planning to create breaches that get to the information they want without detection and hopefully opening up a long-term conduit for extraction. Again, it is this change in the adversary that the traditional AV suites have failed to embrace.
I also agree on the notion that the actual attack process does not have to be exotic or elaborate. Why spend time going through the trouble of designing and engineering a zero day when there are numerous exploits created and widely deployed through production software? The time and energy is better spent gaining information about how and what to attack and what to do when successful. Which of course supports the APA notion: it is the advanced profile and skill of the adversary that makes these attacks so problematic, not the attack.
Here is where I wade into danger. The most common thread among of these posts is the notion that there is no one vendor-produced solution for APT (or APA). Crawford and Selby warn of the vendor “easy button” and Rich Mogull notes on an associated blog entry that “Every vendor who tells me they can ’solve’ APT instantly ends up on my snake oil list. There isn’t a tool on the market, or even a collection of tools, that can eliminate these attacks.” (emphasis from Mogull).
We agree. Let me state for the record that Triumfant is most certainly not a solution for APT nor can we eliminate these attacks. What we do have is a tool that takes a completely different approach to detection, identifying changes at the granular level to trigger analysis. And we think this approach has solid applications in detecting APT activities (or the work of the APA).
I will stop here hopefully short of pegging Mogull’s snake oil sensors. Yes, I am a vendor and yes the company stands to benefit from using APT as a discussion point for selling our product. But I have talked to enough people here in the DC area engaged daily against the APA that I understand that and effective method of anomaly/change detection is a necessary tool in detecting the work of the APA. I will go deeper into our detection capabilities specific to APT in a later post. Until then, I will continue to read the ongoing discussion with interest.
Click here to subscribe
February 16, 2010 at 9:15 am |
[...] is the case with the recent Google Attack, aka Operation Aurora. Given the discussions around the Advanced Persistent Threat (APT) and attacks like Aurora, I asked our CTO, Dave Hooks, to analyze the available data and provide [...]