What Constitutes a Cloud Product?

Yesterday, there was a pretty heated twitter debate between Ron Miller, Irina Guseva, Tony Byrne, and myself over what constitutes a Cloud Product. This was triggered by an article that Irina had published on the Real Story Group blog about what people should take away from the Adobe security breach (besides passwords).

I am not a big fan of how Irina portrayed cloud security as cloud systems are often more secure than many internal systems. Ron had more fundamental issues with the article.

Adobe calls this product Creative Cloud when it’s not a cloud product.


This had nothing to do with them being cloud. Adobe ID goes back years.

I tend to ignore most contradictions in a Twitter debate given the limits of the medium. I do want to counter both of Ron’s statements.

Cloud Product is Cloudy

This is a simple one. The Creative Cloud can be used as a cloud product. While CIO at AIIM, we had a very common problem. Our marketing team had multi-file pieces of content. If you’ve ever tried to store those files in a Content Management System (CMS), you know the challenges. Links can be broken. Some links are relative and others are absolute. The easy, and almost only, way to solve it was to create a network share drive using CIFS or some other method to fool the Adobe applications.

With the Creative Cloud, you can store the files in the cloud and share them with others in your organization. All of the sudden, it was possible to move those files off of the network share drives. Those files were the only technical things preventing closing the network shares in the local data center. As a bonus, we were able to readily share files with the marketing staff over in the UK without all the mucking about with VPN.

A win-win situation thanks to a very specific cloud application.

It wasn’t much of a cloud solution, but it was one that worked very well. It was on-demand, elastic, and was a service. It is a Cloud product.

And it was accessed by Adobe ID.

Origin is Secondary

I will immediately concede that there is a difference between a native cloud vendor and a vendor moving to the cloud. Cloud vendors live or die on security. Security is their basis for trust. They just love to pile up the certifications, hoping to have the ones needed to be trusted by potential clients. One too many issues and people will not use their service, ever.

Vendors that are creating new cloud offerings to either augment or replace their current product portfolio can leverage the trust that they’ve been building in the market for years. While it doesn’t alleviate the need to secure their products, it does diminish the internal obsession with security.

Adobe created a login for their web properties years ago. It made sense to extend that existing system to manage the logins of people using their Creative Cloud. What had been simply a login for a website evolved into a login to access content stored in the cloud.

When the passwords were hacked, it became a cloud security breach. Maybe not all 38 million ids had cloud accounts, but it only takes one of those accounts to be a cloud issue.

I am not going to guess as to what really happened. I suspect that Adobe failed to do their math homework.

The Security Equation

There are many ways to determine how much security is enough. One of the ones that I learned was to make sure that the amount of security in any system was strong enough to make the hacking of the system not worth the required effort. As you can’t make any system hack-proof, it is a good measure of how far to go before stopping.

Adobe had a system that was secure enough at first. Then they started storing content for their customers. Access to license keys, software, and forums isn’t too valuable, especially when the software can usually be found in the software pirate networks. Content is something else.

When content was added, the equation shifted. The benefit of hacking the system grew dramatically. The security implemented by Adobe either wasn’t upgraded or wasn’t improved enough. The result, they were hacked.

Cloud is Cloud

It doesn’t matter the vendor, a cloud product is a cloud product. It only takes a little cloud before it is a cloud product. Having a cloud product doesn’t change the DNA of the company though. The problem is that it needs to change.

Once you enter the cloud, you have to up your game in the security world. You have to hire security experts and attempt to hack into your own systems. You can not delegate security to your clients. You have to own security and make it a core part of you.

Adobe likely didn’t do that. I suspect that they will now.