HP Cloud Services, Cloud Pricing and SLAs

Lead Analyst: Cal Braunstein

Hewlett-Packard Co. (HP) announced the HP Cloud Compute made generally available in Dec. 2012 while the HP Cloud Block Storage cloud entered beta at that time. HP claims its Cloud Compute has an industry leading availability service level agreement (SLA) of 99.95 percent. Amazon Inc.'s S3 and Microsoft Corp.'s Windows Azure clouds reduced their storage pricing.

Focal Points:

• HP released word that the HP Cloud Compute moved to general availability on Dec. 5, 2012 and will offer a 99.95 percent monthly SLA (a maximum of 22 minutes of downtime per month). The company extended the 50 percent discount on pricing until January. The HP Compute cloud is designed to allow businesses of all sizes to move their production workloads to the cloud. There will be three separate availability zones (AZs) per region. It supports Linux and Windows operating systems and comes in six different instance sizes, with prices starting at $0.04/hour. HP is currently supporting Fedora, Debian, CentOS, and Ubuntu Linuxes, but not Red Hat Enterprise Linux (RHEL) or SUSE Linux Enterprise Server (SLES). On the Windows side, HP is live with Windows Server 2008 SP2 and R2 while Windows Server 2012 is in the works. There are sites today on the East and West coasts of the U.S. with a European facility operational in 2013. Interestingly, HP built its cloud using ProLiant servers running OpenStack and not CloudSystem servers. Meanwhile, HP's Cloud Block Storage moved to public beta on Dec. 5, 2012; customers will not be charged until January at which time pricing will be discounted by 50 percent. Users can create custom storage volumes from 1 GB to 2 TB. HP claims high availability for this service as well and claims each storage volume automatically is replicated within the same availability zone.
• Amazon is dropping its S3 storage pricing by approximately 25 percent. The first TB/month goes from $0.125 per GB/month to $0.095 per GB/month, a 24 percent reduction. The next 49 TB prices per GB/month fall to $0.080 from $0.110 while the next 450 TB drops from $0.095 to $0.070. This brings Amazon's pricing in line with Google Inc.'s storage pricing. According to an Amazon executive S3 stores well over a trillion objects and services 800,000 requests a second. Prices have been cut 23 times since the service was launched in 2006.
• In reaction to Amazon's actions Microsoft's Windows Azure storage pricing has again been reduced by up to 28 percent to remain competitive. In March 2012 Azure lowered its storage pricing by 12 percent. Geo-redundant storage has more than 400 miles of separation between replicas and is the default storage mode.

Unnecessary Catastrophic Risk Events

Lead Analyst: Cal Braunstein

Knight Capital Group, a financial services firm engaged in market making and trading, lost $440 million when its systems accidentally bought too much stock that it had to unload at a loss and almost caused the collapse of the firm. The trading software had gone live without adequate testing. In other news, Wired reporter Mat Honan found his entire identity wiped out by hackers who took advantage of security flaws at Amazon.com Inc. and Apple Inc.

Focal Points:

• Knight Capital – which handled 11 percent of all U. S. stock trading so far this year – lost $440 million when its newly upgraded systems accidentally bought too much stock that it had to unload at a loss. The system went live without adequate testing. Unfortunately, Knight Capital is not alone in the financial services sector with such a problem. NASDAQ was ill-prepared for the Facebook Inc. IPO, causing losses far in excess of $100 millions. UBS alone lost more than $350 million when its systems resent buy orders. In March, BATS, an electronic exchange, pulled its IPO because of problems with its own trading systems.
• According to a blog post by Mat Honan "in the space of one hour, my entire digital life was destroyed. First my Google account was taken over, then deleted. Next my Twitter account was compromised, and used as a platform to broadcast racist and homophobic messages. And worst of all, my AppleID account was broken into, and my hackers used it to remotely erase all of the data on my iPhone, iPad, and MacBook." His accounts were daisy-chained together and once they got into his Amazon account, it was easy for them to get into his AppleID account and gain control of his Gmail and Twitter accounts. It turns out that the four digits that Amazon considers unimportant enough to display on the Web are precisely the same four digits that Apple considers secure enough to perform identity verification. The hackers used iCloud's "Find My" tool to remotely wipe his iPhone, iPad and then his MacBook within a span of six minutes. Then they deleted his Google account. Mat lost pictures and data he cannot replace but fortunately the hackers did not attempt to go into his financial accounts and rob him of funds.
• All one initially needs to execute this hack is the individual's email address, billing address and the last four digits of a credit card number to get into an iCloud account. Apple will then supply the individual who calls about losing his password a temporary password to get access into the account. In this case the hacker got the billing address by doing a "whois" search on his personal domain. One can also look up the information on Spokeo, WhitePages, and PeopleSmart. To get the credit card information the hacker first needed to get into the target's Amazon account. For this he only needed the name on the account, email address, and the billing address. Once in, he added a bogus credit card number that conforms to the industry's self-check algorithm. On a second call to Amazon the hacker claimed to have lost access to the account and used the bogus information in combination with the name and billing address to add a new email address to the account. This allows the hacker to see all the credit cards on file in the account – but just the last four digits, which is all that is needed to hack into to one's AppleID account. From there on, the hacker could do whatever he wanted. Wired determined that it was extremely easy to obtain the basic information and hack into accounts. It duplicated the exploit twice in a matter of minutes.

RFG POV: The brokerage firm software failures were preventable but executives chose to assume the high risk exposure in pursuit of rapid revenue and profit gains. Use of code that has not been fully tested is not uncommon in the trading community, whereas it is quite rare in the retail banking environment. Thus, the problem is not software or the inability to validate the quality of the code. It is the management culture, governance and processes that are in place that allows software that is not fully tested to be placed into production. IT executives should recognize the impacts of moving non-vetted code to production and should pursue delivering a high quality of service. Even though the probability of failure may be small, if the risk is high (where you are betting the company or your job), it is time to take steps to reduce the exposure to acceptable levels. In the second case it is worth noting that with more than 94 percent of data in digital form commercial, government, and personal data are greatly exposed to hacking attacks by corporate, criminal, individual, or state players. These players are getting more sophisticated over time while businesses trail in their abilities to shore up exposures. Boards of Directors and executives will have to live with the constant risk of exposure but they can take steps to minimize risks to acceptable levels. Moreover, it is far easier to address the risk and security challenges in-house than it is in the cloud, where the cloud provider has control over the governance, procedures and technologies used to manage risks. IT executives are correct to be concerned about security in cloud computing solutions and it is highly likely that the full risk exposure cannot be known prior to adopting a vendor's solution. Nonetheless, Boards and executives need to vet these systems as best they can, as the risk fiduciary responsibility remains with the user organization and not the vendor.