Well it looks like I was right when I wrote a few days ago that my gut told me security was not the real reason the Google / City of LA project was delayed. Channel Web had excepts from a letter by the LA City officials to Google from last April. Here are some of the quotes:
The April 13 letter, addressed to L.A.’s information technology and government affairs committee from City Administrative Officer Miguel A. Santana, notes that during a pilot program testing the Google Apps system, which was deployed by Google implementation channel partner CSC, users voiced frustration over performance issues.
The letter noted that a working group to test the pilot program convened to discuss its findings. Many users were disappointed at the lack of features similar to the ones in the city’s old Novell (NSDQ:NOVL) GroupWise system. Users also said they experienced less than acceptable speeds in certain areas of the city.
Some pilot participants also identified new capabilities that were not available to City staff using GroupWise, including collaboration tools, chat, and compatibility with a wider range of mobile devices.
So lets put the cloud security bogeyman back in the box. The real reason for the delay here is that Google Apps may not be ready for prime time. But to say that it was a cloud security issue is misleading.
I was reading an article by Larry Walsh, over at Channel Insider earlier today. It is called “A Certificate to Prove You Are Cloud Worthy“. I think it should be a certificate to prove you are cloud savvy, but that is another story. In any event the CSA is going to start offering a Certificate of Cloud Security Knowledge. Hey why not. The security industry certainly does not suffer from any shortage of different certificates to attest to your knowledge or thirst for certificates. Why not add one more to the list. BTW if you are interested you can download the materials to prepare for the test from the CSA site and they are offering a 100 dollar discount between now and the end of the year.
Perhaps more importantly though, this got me thinking again about cloud security. For the last 8 or 9 years I have heard the security industry say we need “security baked in, not bolted on”. Even here at Alert Logic, the SaaS security solutions monitor your cloud infrastructure for alerts and compliance. Almost by definition that is bolted on security. And it is not Alert Logic alone on this. Our entire security industry is based on the same paradigm.
With the cloud we have a chance to change the rules. Security can be baked in. We are seeing it with some of our cloud provider partners, baking in the Alert Logic SaaS solutions right into the stack. This baked in security by design can be a game changer.
In my last two articles I wrote about Google Apps and security concerns. None of those security concerns dealt with the ability to detect attacks, vulnerabilities or monitor logs and such. They dealt with secure architecture. The cloud does offer some twists and wrinkles different than an enterprise. Data is on a shared platform. Access to that data could be by users who are not your employees.
The cloud needs security architects. Not the people who architect where a firewall goes or how to route traffic, but how to design secure infrastructure. This is a huge need and if I were getting into security today, it is something I would want to be in.
I would love to see the CSA offer a course and certification in designing secure cloud infrastructure. How about it?
Yesterday I wrote aboutGoogle and the City of Los Angles delayed cloud deployment due to potential security concerns (or maybe not). Today comes word that Google Apps has been certified under the Federal Information Security Act (FISMA). This means the government has given Google Apps its stamp of approval for all but classified government functions. This is believed to be the first certification of a cloud based application for the federal government.
So my question is what changed? Are the Federal Government’s security concerns any less than the State of California’s? I would think not. Is this just another case of FUD around cloud security in the LA case?
Perhaps it is more of what I was writing about yesterday. Maybe security concerns were only part of the problem in the City of LA case. Maybe delays delivering email via Gmail and other technical issues were at play here. While it may be trendy and convenient to lay the blame for the delay at the feet of cloud security, there is more than meets the eye there.
So now the question is: If it is good enough for the Federal Government, shouldn’t it be good enough for you? Lets see more cloud apps and cloud computing being certified for sensitive environments. Despite the naysayers, there are plenty of SaaS-based security services like Alert Logic out there that can handle cloud security. The cloud can be a lot more secure than many believe.
OK I am recharged and back from a great vacation, but the cloud did not shut down while I was away (I guess that is a good thing). There was a bit of controversy last week over the fact that the much ballyhooed Google-CSC project to move the City of LA to the cloud was delayed. The delay could cost Google and their partner CSC significant dollars due to promised deadlines being missed. No one likes to miss deadlines, but I think reading between the lines the screaming headlines of “security issues force delays” are not necessarily true either.
Reading some of the these headlines you would think there were bonafide security issues that forced this project to run aground. However, like much of the hype around cloud security, on closer observation, it may not have been true security issues which caused this delay.
According to what I have read there were several reasons why this project missed its deadline:
1. Some delivery issues around Google email which is part of the Google Apps deliverable in the project. Meaning that the mail was not evidently being delivered in a timely matter. Not a security issue at all.
2. Technical issues some created by the City of LA, others by Google and CSC.
3. Background checks on all Google employees who could have access to sensitive data. While this is certainly a security issue, it is not just a cloud issue, but instead SOP for any type of deployment of sensitive data storage.
4. New issues around data encryption and segregation that were raised after the initial requirements were set. Again reading between the lines, it would appear that that California Dept of Justice and the LA Police department came in after the fact and decided that they wanted to see more information on how the data stored in the cloud is encrypted and segregated. This type of after scoping feature creep has derailed many a project before this, cloud or no cloud.
It is also important to remember that by the city of LA’s own admission, Google has delivered on everything they had promised to on time. This is what one article said, “The source added that so far Google has delivered the features and functions promised and has fulfilled the security requirements outlined at the project’s inception.”
So before we see the everyone run out and start using the Google/City of LA case as an example of the the cloud not being secure or a reason not to move to the cloud, take a good hard look at the facts. It may be just a case of putting the cloud security bogeyman back in the box.
Recently, a partner of mine asked me to look at a website used to crack wireless passwords in the cloud. The site WPA Cracker is defined as:
…a cloud cracking service for penetration testers and network auditors who need to check the security of WPA-PSK protected wireless networks.
So the general idea is only good guys will use this site to see how secure their WiFi network may be. It is a noble cause, but let us not kid ourselves, any tool a good guy can use, will likely be used by a bad guy. Just like the cloud, it can a great tool (when used properly and securely) to enable organizations to do more, with less internal resources, but it can provide the same benefits to the bad guys. They can easily use the cloud to stream-line their processes and procedures to make them more agile, more focused, and generally more evil.
Bad guys using the cloud for evil is nothing new. I remember when rainbow tables and NTLM hashes were first places online. Prior to that, you would have to compute your own which required gigs to terabytes of storage. People began developing desktop agents similar to the SETI project to leverage peer-to-peer computing to crack passwords in seconds. So this site is not the first to leverage this concept.
What does this mean for us? It means that regardless of how excited we get over new ideas and concepts in terms of business enablement, we can not forget the basic tenants of Information Security. We have to continue to be on our toes, and realistic that we are only secure for a moment. The best we can do is to extend that moment as long as possible, focus on new technologies that makes us even more secure, and remember that prevention is only half of the game. We most focus just as much on detection and response and look to every company that was ever breached who went to sleep thinking that day would never come.
When the Data Encryption Standard was proposed in 1977, it was predicted that the computing power to crack the password would take more 72 quadrillion keys to test and the cost of such computing power would be unreasonable. That same year, Diffie and Hellman estimated that such a machine could be built for around $20,000,000US and would take about a single day. In 1998, the Electronic Frontier Foundation built a system for $250,000 and cracked DES in 2 days. Since then, DES has been broken in less than one day, using hardware that costs less than $10,000. None of these techniques leveraged cloud-computing, which as we see with the WPA cracker, shows us that we will always be changing encryption standards, as well as watching the bad-guys as much as the bad-guys are watching us.
Increasingly, IaaS market leaders will rely on infrastructure SaaS providers to complement their core capabilities and round out their offerings, starting with security and compliance.
Whether you are a managed hosting provider seeking to move up-market into enterprise hosting, or a cloud service provider seeking to add managed services, you face a strategic challenge in filling the void between simply deploying raw infrastructure as a service (e.g., a provisioned but unmanaged OS instance) and offering your business customers a fully-managed infrastructure stack. As an IaaS provider, your job is to integrate best of breed solutions into a coherent whole. Automation is key.
In the traditional/discrete hosting world, the toughest nut to crack in the IaaS realm has been security and compliance. This has led Chris Hoff to proclaim “security doesn’t scale.” This is a key reason why so few Enterprise Hosting companies exist, and why the leaders in this segment tend to have dedicated MSSP business units to deliver the security and compliance layers of the infrastructure stack. (And even then, as several of these MSSPs have demonstrated, their home-grown solutions do not scale well – up or down.)
When it comes to managed security and compliance services, SaaS is the way to go. Security SaaS providers are not just vendors, they are your partners in deploying a complete IaaS solution for your customers. With security being an increasingly key element of the infrastructure stack, and security services being revenue-producing for IaaS providers, Security SaaS is the leading example today of revenue-producing Infrastructure SaaS. This new market segment will expand further as public cloud services proliferate.
In the new world of public clouds, incorporating security and compliance into an integrated IaaS solution will be even tougher without leveraging a customer-facing SaaS solution from a software vendor focused on security and compliance. As previously discussed, cloud service providers are dealing with way too much complexity to moonlight as security SaaS companies.
IaaS customers are growing increasingly accustomed to this, and we expect the market to continue evolving in this way, with IaaS providers serving as aggregators of infrastructure services – some provided by themselves and others provided by SaaS specialists – and differentiating primarily through integration, automation and customer service.
Whereas security and compliance has been the shining example of infrastructure SaaS benefiting the traditional hosting world (as Alert Logic has shown through its successful partnerships with more than 15 of the global leaders in hosting), with public clouds there will be far more infrastructure SaaS opportunities in areas ranging from storage to middleware to security.
As discussed previously, the trick in moving to these levels of service lies in automating not only the provisioning, metering and billing for service, but also automating support for each layer of the IT stack. Support automation is tough. SaaS specialists at each layer of the stack (such as Alert Logic in security and compliance) have the unfair advantage … cloud providers will leverage this advantage in building the secure cloud.
This is part 7 in a running series of posts by Gray Hall, CEO of Alert Logic on the future of the Service Provider industry. Gray’s experience and background give him a unique vantage point to comment and help lead what the Service Provider of Tomorrow has to do in order to be successful. Parts 1, 2, 3, 4, 5 and 6 are also available here on Secure Cloud Review.
A few weeks ago one of my SCR co-authors asked if Open Source Matters to cloud security. For me, the bigger question was whether open source mattered at all. Despite the fact that most cloud providers make extensive use of open source technologies, Amazon, Google, GoGrid and Rackspace have one thing in common with Microsoft – their core provisioning, networking, storage and management components are essentially a black box for the users. Until now.
Today Rackspace, NASA and 25 other companies announced a new effort called OpenStack that provides a set of open source components for building an infrastructure cloud. If OpenStack can fulfill on it’s promise, the effect on cloud computing and by extension to cloud security will be profound.
To be fair, this isn’t as much of show of strength of Rackspace cloud technology as it is a chance to win the game by changing the rules on the field. Until now, IaaS providers competed on the strength of their ability to rapidly advance their software capabilities. By commoditizing the software behind infrastructure clouds and pulling in a sizeable development community Rackspace may be able to force Amazon to compete on their own terms – the strength of being a service provider. This is the “softer side of Sears” that AWS has historically lacked in both it’s service and it’s company culture and an area where Rackspace excels.
My personal interest in the OpenStack was whether it would finally provide the opportunity to built security directly into the cloud fabric. Most cloud providers (especially Amazon) do not focus on building security capabilities until they are forced to do so by their customers and are notoriously hesitant to partner with security companies, because they require rather deep access to network and software components. As an open source ecosystem, the Open Stack allows developers interested in adding security capabilities to have equal access to the cloud platform like never before.
There are few technical details available on the project site, but the agenda notes from the recently held design summit provide some interesting details for those interested in cloud security:
OpenStack is not the software that runs the Rackspace Cloud today, but a new project built by combining the NASA’s Nova and Rackspace Ozone projects that each has been building as a next-gen architecture for their infrastructure clouds.
While the storage component of OpenStack is available now (with support for AoE, iSCSI, pNFS under consideration), the compute code should be available closer to end of the year.
OpenStack should have more mature networking capabilities than currently available with RS CloudServers today, including VLANs and VPN support, courtesy of Nova.
More advanced networking and security functions may come from Open vSwitch, which appears to be under consideration.
CloudAudit capable API is also under consideration, which may be the first known implementation for this recently submitted IETF draft.
Access API may accommodate for an IT Security group for dealing with compromised guests.
OpenStack will provide audit logs of “who did what to cloud resources”, which would be a welcome change from the way most providers operate today.
There are a lot of open questions about the OpenStack. Does 1+1=2 when you merge the NASA Nova and Rackspace Ozone projects into a single code base? How will companies like Citix actually contribute to this project and will ever find a way to monetize XEN within public cloud providers? Will this effort actually take off?
I expect OpenStack to not only be successful, but have real impact on the way cloud computing evolves, if for no other reason than it allows Infrastructure-as-a-Service providers to actually focus on service. If you’re having doubts, consider this: even more significant than participation from infrastructure companies like Citrix and Intel is participation of a number of service providers – and Rackspace competitors – such as Peer1, SoftLayer, IOMart and others. This, more than any other fact gives the OpenStack legitimacy and suggests that OpenStack could be a major event in evolution of cloud computing and by extension, cloud security.
Ellen Messmer over on CSOOnline had a great article up this week entitled “secrecy of cloud computing providers raises IT security risks“. Ellen does an excellent job describing how cloud providers being vague and obscure about their security policies, process and practices are not doing themselves or their customers any favors. As I have written before, I believe that the cloud is not going to wait for everyone to agree on how to secure it. But that being said, cloud providers who want to gain an advantage on their competitors would be wise to head the lessons in this article.
I thought my friend Andreas Antonopoulos, from Nemertes Research said it well. From the article:
“If your service provider won’t give you information about security processes and plans in order to do what’s necessary, you shouldn’t trust that provider,” said Andreas Antonopoulos, an analyst with Nemertes Research.
The old idea of “security by obscurity,” which suggests you can defend your security position best by keeping mum about everything, is misguided, he said. “It doesn’t work. There’s always someone who knows,” Antonpoulos said. If you hear someone try to get your business by uttering that phrase, “run far and fast.”
I agree wholeheartedly. Securing the cloud is far from perfect today. But then again securing anything is far from perfect. But as Ellen says in her article and is echoed by both analysts and customers, waving a SAS70 audit or a PCI audit is not securing the cloud. As John Pescatore of Gartner said in the article, “SAS-70 certification of any public cloud provider may be considered adequate for some customers, and not others. “SAS-70 is pretty meaningless from a security level, but it makes auditors happy.”
That is so true. I have seen not only cloud providers but even managed security providers hide behind the shield of their SAS70 audit. It is just not enough frankly. You really need to peel the onion back deeper than that.
Also if your cloud provider will not even tell you where your data is kept, I would not be real comfortable with that provider. But Google does exactly that and contends that makes you more secure.
I don’t buy this and either should you. The cloud represents a great way to have economical, scalable infrastructure and platforms that you could not afford to build yourself. But you have a right to ask your cloud provider what they are doing, how they do it and what is their security strategy. If it is security by obscurity, maybe you should look for another provider.
As described in Part 4 of this series, the service levels delivered by public cloud providers – such as Amazon Web Services and Rackspace Cloud – line up with the Dedicated Hosting market in terms of how far up the IaaS stack the service provider goes. To the extent public cloud providers offer an SLA to their customers, they look a lot like Dedicated Hosting SLAs with the key difference being virtual vs. dedicated infrastructure.
Clearly, cloud service providers are working hard to continue climbing the service level stack, and Cloud SLAs will continue to catch up with the SLAs used by traditional IaaS providers. But that road isn’t easy or simple.
Think about it. How many Dedicated Hosting companies have successfully moved up market into Managed Hosting? Not many. Will the task be any easier for cloud service providers? Probably not. Why? Complexity.
Running a hosting business is complex. Hosting companies are the systems integrators of the future. Hosting is about integrating IT infrastructure systems into a centralized multi-tenant environment, with as many shared components as possible while providing individual customers with the performance and security they require. There are a lot of moving parts in the hosting model, and even after more than a dozen years of refinement the model remains tough to execute. Few do it well. Adding to the degree of difficulty, the demand for hosting continues to boom. For years, hosters have been trying to refine and improve their operating models while growing at breakneck speed. This has proven to be almost as hard as re-engineering an aircraft while in flight.
Against this backdrop, hosting providers are now rushing to deploy public cloud, private cloud, and hybrid cloud solutions for customers. These products are more complex than traditional hosting products, mostly because individual billing units are no longer associated with discrete infrastructure devices.
One silver lining is that cloud solutions are so complex that few will attempt to offer these solutions without a foundation of operations automation in place. So cloud service providers and their customers will be partially protected from an unfortunate tendency of human nature that has caused its share of pain the hosting industry thus far … scaling first and automating later.
But, by the same token, the degree to which cloud service providers can climb up the infrastructure stack will be throttled by automation. The current providers of public cloud services have mastered automated provisioning, metering and billing of virtual server instances across a shared computing environment … hence the current service levels reflected in the chart above. But going further up stack will require automating the provisioning, metering, billing and support of the next layers of the IT infrastructure stack. In an integrated fashion. This is – categorically – a more difficult challenge.
Meanwhile, demand for public cloud services is growing even faster than demand for traditional hosting. For Rackspace, Opsource and other hosters who have launched public clouds, their cloud products are their fastest-growing sources of new revenue.
There is a large gap between the current service levels delivered by public cloud providers and the Enterprise Hosting SLA. The problem is not market demand; the demand is there. The problem is the degree of difficulty in delivering the full IT infrastructure stack, fully automated, on a fully virtualized platform. How can cloud service providers bridge this gap? How long will it take? Please tune in for our next installment.
This is part 6 in a running series of posts by Gray Hall, CEO of Alert Logic on the future of the Service Provider industry. Gray’s experience and background give him a unique vantage point to comment and help lead what the Service Provider of Tomorrow has to do in order to be successful. Parts 1, 2, 3, 4 and 5 are also available here on Secure Cloud Review.
In recent news, Cisco Live 2010‘s attendee list was hacked due to a security breach. The first questions everyone has after a breach are:
What was taken?
How was it taken?
Who took it?
How do we keep this from happening again?
We don’t know all the answers at this point as it would appear, Cisco doesn’t really even know what all was accessed. Regardless, this got me thinking about perception of low-impact theft in the cloud. In this case, it is very likely that Cisco, hopefully, was only storing names, e-mails, companies, and common Linked-In-type information. Regardless, as companies look at ways to off-load mundane services to Cloud providers, what if this information begins being used for other nefarious purposes?
While contact information might seem a lot less valuable to the traditional cyber-criminal, in terms of corporate espionage, it can be a Holy Grail. Imagine if a sales-focused organization‘s SalesForce.com information is compromised, what all information are they keeping on their customers and potential customers? What would happen if their rivals had access to that information?
While the move to cloud-based services is no less secure (and in some cases more secure) than a traditional enterprise security posture, we need to be asking questions at all times about how our data is being protected. What could be a simple contact list, could lead to public embarrassment, civil liability, and may lead to more problems.
Secure Cloud Review is a forum to discuss relevant topics regarding cloud computing, service providers and security.
SCR is sponsored by Alert Logic, providers of cloud-powered solutions that provide the smartest way to secure your networks and comply with regulatory mandates.
My personal interest in the OpenStack was whether it would finally provide the opportunity to built security directly into the cloud fabric. Most cloud providers (especially Amazon) do not focus on building security capabilities until they are forced to do so by their customers and are notoriously hesitant to partner with security companies, because they require rather deep access to network and software components. As an open source ecosystem, the Open Stack allows developers interested in adding security capabilities to have equal access to the cloud platform like never before. 
