HBGary's Gmail Hack Shows Process Is Vital in Managing Cloud Risk

Analyst(s): John Pescatore
Free preview of Gartner research
Summary
HBGary's Gmail cloud e-mail was compromised by a stolen password -- but it was poor incident-response process that failed to protect vital data. Enterprises should focus on SLAs prior to choosing cloud services to assess risk.
Table of Contents
News Analysis
Event
On 17 March 2011, new details emerged about the hacking of security firm HBGary's Google cloud e-mail service by the Anonymous group in February 2011. HBGary had gained high visibility after a high-ranking employee of a related company, HBGary Federal, made public statements about infiltrating the Anonymous group group in relation to the WikiLeaks incident in October 2010. An interview with HBGary CEO Greg Hoglund reveals that Anonymous gained access to HBGary's Google-hosted e-mail service through a stolen password. Hoglund became aware that the service was compromised, but was unable to prove his own identity to Google's help desk sufficiently quickly to have the service shut down before Anonymous had downloaded his e-mail.
Analysis
This security incident was a successful attack against HBGary, not against Google's cloud-based e-mail. It exposed no vulnerabilities in Google's service. But it did expose the risk of "one size fits all" service-level agreements (SLAs), which many cloud service providers generally impose in order to reduce the price of their services. While enterprise providers invariably offer different tiers of service with higher-touch, faster-response support offered at a higher price, many consumer-oriented offerings do not. When HBGary's visibility skyrocketed after the public statements from HBGary Federal, its management should have realized attacks were likely and tested its incident-response processes.
Google's standard mechanism for authenticating a customer making service requests involves asking the customer to place a file on its own website. This works well in normal circumstances but failed when HBGary needed to immediately turn off access to its Google services after having already been forced to shut down its own website. No alternate or emergency response mechanisms had been defined in advance. Google had recently started offering two-factor authentication mechanisms, but HBGary had not taken advantage of that capability.
As a security company itself, HBGary should have realized the risk involved in using e-mail as a service in general, and in the potential pitfalls of the authentication approach for making emergency service changes when it signed the contract with Google. But cloud service providers such as Google should also offer either emergency access processes or higher-priced, higher-tier direct support for their enterprise customers, just as most enterprise product and service providers do.
Recommendations
Enterprises already using cloud-based services:
-
Review all service incident response SLAs to assure that authentication mechanisms or other conditions will not limit your control of your service in an emergency situation. Have plans to test incident response processes if your visibility or likelihood of attack increases.
Enterprises evaluating cloud-based services:
-
Include requirements for emergency support as key evaluation criteria in evaluating cloud services. Review all cloud service provider SLAs against your own incident-response processes to assure that your prospective cloud provider can meet your required incident response times. Have plans to test incident response processes if your visibility or likelihood of attack increases.
Recommended Reading
Some documents may not be available as part of your current Gartner subscription.
-
"Securing and Managing Private and Public Cloud Computing" — Cloud computing poses a whole new set of risks that must be assessed, including access management and vendor-related risks. By John Pescatore
-
"Google/GSA E-Mail Contract Heats Up Race for Government Cloud Business" — Parts of the U.S. government have moved their e-mail service to the cloud to achieve cost savings, but the risks are not yet fully understood. By Matthew Cain and Andrea Di Maio