The Google Microsoft Security Dust-up and the Marketing Genius Behind the Scenes

I have watched in amusement as people have responded to the claims by Google that they will no longer use the Microsoft operating systems because of the alleged security problems with the MS software.  There are some painfully obvious elements of genius by Google here that people are simply missing in the hysteria:

  • Genius Idea #1:  Google is introducing an operating system, Chrome OS, by the end of the year.  So of course they need to move their staff to Google products and more specifically, away from the Microsoft products.  Given Google is smart enough to not move their entire operations to a new OS on day one, they can get off of MS now to Linux or MAC OS to eliminate the PR ambiguity.  In other words, they cut the MS chord without putting all of the their operational chips on the Google OS square.  Genius.
  • Genius Idea #2:  Where is the official statement by Google?  Everything I have read had quotes from “one Google employee”.   They get the word out, enjoy all of the publicity, and keep their executive team free from any involvement.   There are no defamation suits to file and no one at Google for Microsoft to attack in the press.  Genius.
  • Genius Idea #3:  Google’s decision means that any other company that wants to move away from Microsoft no longer has to bear the risk of going first.  Google is respected (well, they keep trying to screw that up) technology leader.  If they can ditch MS, then so can any other company.  Genius.
  • Genius Idea #4:  They have clearly planted the flag on why organizations will want to look at the Chrome OS – security.  It is unlikely that the Chrome OS will have a wealth of differentiating OS features, so Google needed to create a clear reason to make the switch.  Declaring (albeit through “one Google employee”) the move is security based and pulling in the Operation Aurora buzz as a catalyzing factor, Google has kick-started the brand for Chrome OS.  Genius.

I wear many hats at Triumfant – CMO, product management, product marketing – but when I look at this from a marketing point of view I am really impressed by this move.  Google has managed to make multiple strategic moves at near zero costs and no “official” entanglements.  They create buzz, establish some brand awareness, and begin the “eat our own dog food” process with some perceptive guerrilla marketing.  Genius.

I have long contended that the disclaimer at the end of erectile dysfunction medicine commercials was added not by legal but by marketing.  You know, the disclaimer about certain conditions lasting longer than four hours.  The marketing person likely said “You really want everyone to remember this commercial? Then put in this disclaimer and everyone will be talking about it.”   It worked.  Genius.

So today the blogosphere and Twitterverse is buzzing loudly with the Google move.  Bravo Google marketing person.  Well done.  Genius.

Triumfant and Operation Aurora – Detecting the Advanced Persistent Threat

When new malicious attacks get a lot of attention in the press, we get asked the same question: “would Triumfant have seen that attack?”. Such 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 details on how Triumfant would respond if Resolution Manager had been deployed on an endpoint machine or server that was exposed to this attack.   Dave’s response is illustrative of how Triumfant works in the context of an actual attack and how our unique capabilities enable Triumfant to detect an attack with characteristics common to those attacks seen in APT.

I offer Dave’s analysis with the full disclosure that it is based solely on detailed analysis of the attack, and that we had no firsthand exposure to the attack itself.  Dave broke his analysis into four parts: initial detection, diagnosis, knowledge base, and remediation, showing how Triumfant can identify an attack without prior knowledge, diagnose the attacks and correlate all of the changes to the machine associated with the attack, and build a situational and contextual remediation to return the machine to its pre-attack condition.

———-

Analysis of Operation Aurora

Initial Detection

Operation Aurora creates several service keys during three specific steps: execution of the dropper, the first stage of installation, and the second stage of installation.  Some of these keys are subsequently deleted but at least one is persistent.  The appearance of one or more of these keys would trigger the Triumfant agent’s 30 second scan cycle for markers of malicious activity, resulting in the agent requesting permission to execute a fast scan.  The Triumfant server would respond within seconds, green lighting the scan.  The agent would then capture the state of the machine immediately after infection and send the data to the server for analysis within 3 minutes.

Diagnosis

The Triumfant server would receive the snapshot, recognize that is was executed as a result of suspicious behavior, and immediately compare it to the adaptive reference model (the unique context built by our patented analytics).  The result of this comparison would be a set of anomalous files and registry keys.  The fact that the files and keys associated with Operation Aurora have random names would guarantee that they would be perceived as anomalous despite the fact that humans might tend to confuse them with legitimate Windows services.  Further analysis would then be applied to the anomaly set to identify important characteristics and functional impacts.  In this case the salient characteristics would be an anomalous service and a number of anomalous system32 files.

The discovery of an anomalous service would cause the Triumfant server to launch a probe requesting the Triumfant agent to explore the service further.  The probe would contain a list of all of the anomalous attributes found by the server during its analysis.  The Triumfant agent would activate a series of correlation functions to partition the anomalous attributes into related groups.  In this case it would group all of the anomalous attributes related to Operation Aurora.  It would then perform a threat analysis on this group and discover, for example, that it was communicating over the internet.  The results of the correlation and threat analysis would then be sent back to the Triumfant server.

At this point the diagnosis would be complete and the Triumfant server would alert the appropriate personnel that an “Anomalous Application” had been discovered and the data would be available on the console.  It would then be possible for an analyst to view all of the persistent attributes of Operation Aurora as well as the corresponding threat analysis, as well as readily share the data with CIRT and forensics teams.

Knowledge Base

An analyst can save the analysis for an Anomalous Application such as Operation Aurora to the Triumfant database.  This would allow the analysis to be converted into a new recognition filter.  Recognition filters have a number of benefits.  First, they provide a very precise mechanism for storing and sharing knowledge about an incident.  Second, they allow the system to search for any other instances of that particular condition in other environments.  Third, they enable the operator to pre-authorize automatic responses such as remediation should that incident be detected again in the future.

Remediation

If a Triumfant server detected Operation Aurora as an anomalous application, it would have sufficient knowledge of the anomalous attributes to synthesize a remediation response.  This remediation would be custom built to exactly match the attributes of the anomalous application on an attribute by attribute basis.  The ability to create remediations on the fly would enable the Triumfant system to surgically and reliably remove the components of Operation Aurora without reimaging the machine.  It would also enable follow on variants to be addressed without the need for new signatures.

———-

Again, let me state for the record that this is based on Dave’s analysis and not actual “live fire” data of our software responding to an actual attack.  But we are quite confident that Triumfant would have responded as described, detecting the attack and building a situational and contextual remediation.