Google Sucker-Punches US Gov

Just a few weeks ago the Washington Post news broke that Google was using a set of loopholes to evade paying US taxes.

Dig a little deeper, and you’ll discover that Google, the company that once promised to do no evil, turns out to be an ingenious tax dodger that has found a way to stash billions of dollars in profit in overseas tax havens. […] Drucker estimates that it saved Google $1 billion a year in U.S taxes between 2007 and 2009.

Actually, Drucker’s estimates and description of the loopholes in the law were far worse.

Google Inc. cut its taxes by $3.1 billion in the last three years using a technique that moves most of its foreign profits through Ireland and the Netherlands to Bermuda. Google’s income shifting — involving strategies known to lawyers as the “Double Irish” and the “Dutch Sandwich” — helped reduce its overseas tax rate to 2.4 percent, the lowest of the top five U.S. technology companies by market capitalization, according to regulatory filings in six countries.

While the US Government must be staring intently at this issue, wondering how its vulnerabilities were exploited and how to restore balance…here comes the Google sucker-punch: a lawsuit after the US government did not choose Google for its email.

I have read the complaint and here is my brief summary:

Google was in extensive discussions and presentations with the Department of the Interior (DOI). They answered numerous questions from the DOI and submitted their best foot forward. At the same time Microsoft was also in consideration. Google was turned down and says they are unable to understand how Microsoft could have won. They cry foul for several reasons such as these:

1) They contend that Microsoft is less “secure” but confess to have no actual knowledge of the system and instead offer a generic estimate of vulnerabilities based on a lopsided disclosure process that also has been called unfair. Moreover, while they point to vulnerabilities they fail to acknowledge that Google itself has had several major breaches that expose weakness in security management such as the Site Reliability Engineer incident. Would you use Google apps if you knew this guy has open access to all of your most sensitive information and is not tracked or monitored?

2) They contend that Microsoft does not have FISMA certification yet but confess that it was not a challenge for Google to achieve it themselves. Google says they segmented their network to have a logical path for domestic-only traffic (hopefully done better than their horribly flawed wireless filters). Easy-peasy, as they say, so why not expect Microsoft to do something equally unimpressive? In my mind Google actually weakens their own position in arguing this point. They are touting segmentation and FISMA certification as proof of difference when just months ago they were totally compromised by Chinese attackers who exploited their flat-network with a simple VPN bypass. A Google employee at the office in China, in other words, had their system compromised and that led to a massive security breach at Google corporate. They tried to blame it all on a flaw with Microsoft software when clearly that flaw easily could have been contained…if not for Google’s poor security management decisions and serious design errors.

This could be really good for security, as two titans compete to see who can be more secure and raise the bar overall. A level field for the cloud market would give a big boost to everyone looking for trusted systems. However a level field could also just give a cheater a bigger advantage. It can be really bad for security if one or both of these same titans are known to play dirty and throw mud and smoke screens. Google definitely seems to be practicing the latter when it comes to security.

Perhaps the US President can settle this easily by bringing all the pieces of the puzzle together and punch back.

A company will only be considered for bids if it has not been found to claim itself a foreign entity and exploiting loopholes in law — using an unfair playing field to reach a corporate tax rate below 5%. Clearly Google is in no position to cry foul from its beach-front property in Bermuda. Their spurious claims to security metrics also could backfire. The debate obviously should not just be a tally of vulnerabilities disclosed but management of security systems and proper breach response. Why were parents the ones to discover and then report abuse of privacy in 2010 by internal Google entry-level engineers? How did a small VPN breach in China get all the way into the most valuable Google code in America? Given just the Aurora and SRE breaches this year the Government is wise also to demand Google prove significant and lasting security management reforms before they can bid on sensitive government projects like email for the DOI.

At the end of the day the Google lawsuit has been explained to me by market experts as a shrewd marketing ploy:

It is a calculated move. They are not suing their customer, just the process. People are going to notice now that Google has a government product.

Perhaps congratulations should go to Google for using an expensive lawyer instead of a marketing firm to make a point. I go back to the above argument, however. This move will be a good one if it increases scrutiny around fairness in selection as well as better cloud compliance for security standards. It will be a bad one if it only increases pressure among competitors to take cheap/misleading shots with security flaw announcements to make each other look bad, while avoiding the underlying management and architecture issues.

Top 10 Database Attacks

AppSec has a nice graphical set of slides that illustrate the most common database attacks. Here they are in reverse order and in terms of remediation:

  1. Encrypt sensitive data at rest and in transit
  2. Patch, patch, patch
  3. Patch vulnerabilities that cause Denial of Service
  4. Patch vulnerabilities that enable privilege escalation
  5. Limit buffers
  6. Turn off unsafe configurations
  7. Remove and/or disable packages you do not use
  8. Restrict privileges to users and groups
  9. Sanitize input
  10. Remove default, blank and weak log-in credentials

I would call that seven, not ten, but see for yourself.

Cloud Expo 2010 Presentation

I will be presenting some smoking-hot compliance information this Wednesday at the 7th Annual Cloud Expo in Santa Clara.

Come hear what Google really means when they say they achieved FISMA certification and why Amazon said their cloud would never be PCI Level 1 certified.

I will break it all down in terms of regulations and introduce you to emerging technology that already is making private and public clouds “safe” if not “trusted”.

HSBC Bank Secrecy Failures

The US Government’s Office of the Comptroller of Currency (OCC) recently released a formal Consent Order related to HSBC compliance failures on the BSA/AML (Bank Secrecy Act/anti-money laundering).

…violations and failures were the result of a number of factors, including, among others, (i) inadequate staffing and procedures in the alert investigations unit that resulted in a significant backlog of alerts; (ii) the closure of alerts based on ineffective review; (iii) inadequate monitoring of Group Entities correspondent accounts for purpose and anticipated activity, anti-money laundering record, or consistency between actual and anticipated account activity; (iv) unwarranted reliance on Group Entities following HSBC Group BSA/AML policies; (v) inadequate monitoring of funds transfers; (vi) inadequate procedures to ensure the timely reporting of suspicious activity; (vii) failure to adequately monitor Group Entities banknote activity, (viii) inadequate monitoring of correspondent funds transfer activity; and (ix) inadequate collection and analysis of CDD [customer due diligence] information, including inadequate monitoring of PEPs [politically-exposed persons].

This is an ironic development given that HSBC was also recently in the cross-hairs of multi-national regulators for an incident involving insider access and database breach.

In that case an employee gained unauthorized access and then tried to sell information on account holders to tax authorities (e.g. Germany could see what their citizens were keeping in Swiss accounts). Some agencies were looking at the opportunity to purchase secret information, while other government authorities demanded access to the same or similar information for free under BSA/AML.

HSBC was did not have sufficient secrecy on one hand while on the other hand it had too much. The problem in both cases was a lack of monitoring for violations related to laws and regulations.