...And You Will Know Us by the Trail of Bits

Now that the media excitement of the aftermath of Operation Aurora has calmed down and we are all soothing ourselves to sleep by the sound of promptly applying Windows Updates, it is a good time to take a look back and try and figure out what the changing threat landscape means for real-world information security (besides Selling! More! Security! Products!) and what lessons can be learned from it.

First off, the threat landscape has not changed at all, only the perception of it.  If you have done or been around any high-level incident response, you would know that these advanced persistent threats have been going on in various sectors for years.  Nor is it a new development that the attackers used an 0day client-side exploit along with targeted social engineering as their initial access vector.  What is brand new is the fact that a number of large companies have voluntarily gone public with the fact that they were victims to a targeted attack.  And this is the most important lesson: targeted attacks do exist and happen to a number of industries besides the usual ones like credit card processors and e-commerce shops.

For the last decade of the information security industry, almost all of the products and solutions have been designed to stop casual opportunistic attackers and mass Internet-scale attacks.  Moreover, these products are absolutely worthless in protecting you from an Aurora-style attack.  Your software vendor doesn’t have a patch for the vulnerability, your anti-virus and/or network intrusion prevention systems don’t have signatures for the exploit or agent it installs, and the 3rd-party software that your business needs to run prevents you from upgrading your desktops to the latest and greatest operating system and/or browser with the most complete exploit mitigations due to a lack of compatibility.  How many of these large security product vendors employ even one full-time person to play the role of a dedicated attacker attempting to bypass or defeat their defensive systems?  Or have even hired one attack-oriented consultant on a contract for an independent assessment of the efficacy of their product or solution?  Don’t let the same product vendors who failed to protect the victims of Operation Aurora turn right around and sell you those same products as a solution to “the APT threat.”

Second, Operation Aurora has no bearing on the vulnerability disclosure debate.  This particular vulnerability was apparently reported to Microsoft in August and scheduled to be patched in February.  Some are arguing that had this vulnerability been reported via full-disclosure to everyone all at once, it would not have been used in these attacks.  They are right.  The reality, however, is that another vulnerability would have been used instead.  These attacks show that the vulnerability disclosure debate and responsible disclosure process is simply a distraction that prevents us from actually improving security.  Remember, a vulnerability never owned anyone — an exploit did.  I am not arguing that vulnerabilities should not be fixed, simply that it is impossible to find and fix every security vulnerability so we should not let that obsession monopolize our efforts and prevent us from implementing more secure application and network designs.

Finally, the larger problem is that it only took one exploit to compromise these organizations.  One exploit should never ruin your day.  Isn’t that why we build DMZ networks with firewalls in front and behind them?  The point of doing that is so that it requires more than one server-side exploit to get into your organization.  Thanks to rich Internet client applications, it now only requires one client-side exploit to get into your organization.  Ideally, it should require around three or four: a remote code execution exploit, a sandbox escape or integrity level escalation exploit, and finally a local privilege escalation exploit in order to be able to install and hide a remote access backdoor on the system.  Also, workstations that receive e-mail and instant messages from strangers, visit random web sites, and download/install whatever software from the Internet should probably not be on the same network as something like your lawful intercept system.

Take this time to review which exploit mitigations such as DEP and ASLR are enabled in your web browser based on your operating system, browser release, and web plugins.  Take ‘/NoExecute=AlwaysOn’ for a spin in your boot.ini and see what (if anything) breaks.  Use this opportunity to get buy-in for placing users’ Internet-enabled workstations onto DMZ-like subnets where you can closely monitor data going in and out.  Give developers remote desktop access to VMs on a separate development network for working on your products (they will be happy as long as you give the VMs more RAM than their workstations so their builds are quicker).  Give everyone access to an external Wi-Fi network to use with their personal Internet-enabled devices.  Get started implementing some internal network segmentation.  Never let a good crisis go to waste.