By Toby Weir-Jones, Vice President – Product Development, Managed Security Solutions Group, BT Global Services

Over the past few weeks, there has been a great deal of coverage given to Google’s announcement that it has been the target of sophisticated network attacks from China.  While many have suspected that western companies and government agencies have been attacked by the Chinese, Operation Aurora was confirmation that online espionage, if not cyber war, is prevalent. 

It’s interesting to note that the purpose of the attacks was not to gain information for immediate profit, as is typically the case, but to keep tabs on the movement of information between individuals, groups, corporations, and government agencies without needing to filter content. 

As has been well documented, Operation Aurora took advantage of a vulnerability in Microsoft’s IE platform.  This continues a pattern of browser-based attacks originating in China against US networks, the most notable of which, until now, being Titan Rain back in 2003.  The specific mode of attack is not new and is not really the story in this case; sadly we’re all familiar with proliferation of attacks against browsers and their plugins, the resulting malware, and ceaseless buffer overflow attacks against thoroughly-vetted products.

But what can companies do to combat these attacks and secure their operations?  After all, not doing business in China isn’t really an option for most companies that are recovering from the economic downturn.  And really, we shouldn’t single out China as the only source of suspicious firewall logs, nor should we assume that addresses originating in the US and Europe should be benign.

What can the CSO do, then, to protect the company and customers?

Product vendors will universally claim they could have detected the attacks because they would have seen it either in the raw network traffic (for NIDS products) or in the application data in memory (for AV and HIDS products).  However, this level of detection relies on buffer overflow alerts that are so generic you’ll never know where the threat is coming from.  In their defense, host products, such as AV and HIDS, can potentially detect the source of the attack as they are application aware.  However, as is often the case, to use these host products effectively, the advanced application protections need to be enabled and not turned off—as many are—to avoid reporting false positives.

On the front-end what we advise our customers to do is to ensure they are monitoring the right devices, and logging is configured correctly.  They also need to ensure that a well-documented and rehearsed incident response plan is in place in the event that a breach occurs.

In the SOC what we’re doing is much more time-consuming.  Our analysts and engineers are relentlessly scouring every log, every security and non-security event, collecting every piece of contextual evidence and sending it back to the lab for analysis, comparing the results of a single customer network against our global customer base to document quickly and accurately that one host in a thousand within a monitored subnet is actually compromised. 

Whether the motivation is fraud, spam, or espionage is technically immaterial because it has no bearing on finding infected hosts or revealing the methods of attack.  What we rely on instead is dozens of combined years of experience in monitoring network security activity; we’re not limited to expertise on one or two technologies, we have extensive knowledge across numerous vendor platforms.  Our CMAL and CBOT modules (first released in 2008) are great examples of advanced technology that solves real business problems, and they don’t simply offer up pretty reports about knee-jerk reactions performed by other devices. 

We want to know where it’s coming from first, and then worry about the details behind what it’s doing.  Security policies don’t distinguish between the details of buffer overflow attacks vs. brute-force — they focus on intent, so focusing efforts purely on signature-based detection can dangerously restrict your view. 

This is the first post in a series about Aurora that we’re working on.  Next up, Rob Jamison, our Manager of Network Intelligence, will offer up more insights into Aurora’s methods of propagation and detection.