Cloud vs On-Premise DAM – Having Your Cake And Eating It
One of our featured DAM vendors, WebDAM Solutions have written an article: The Battle Between Cloud & On-Premise: 5 Things to Consider. The 5 points raised are:
- How will the solution affect my company’s IT team and resources?
- What happens when we want to scale?
- How are updates handled?
- Which solution provides more security?
- Where and when can I access my DAM?
Given that WebDAM are a SaaS vendor, it’s no surprise that they come down in favour of Cloud based DAM systems. The article is not bad and contains some reasonably well argued points, but I have to take issue with a number of them.
This is from the security section:
“Gartner research, a leading information technology research company, states that cloud computing security is typically more secure than what you have today. Of course it depends on the cloud service provider, but if they’re a high esteemed company with a good list of enterprise clients, their security has probably been tested and approved time and time again.” [Read More]
Note the word ‘probably’ here, which is different to ‘definitely’.
The security line especially seems to be one that SaaS vendors are eager to wallpaper over and assure end users that everything will be OK. In reality, you are at risk whether you host with a Cloud platform provider, internally on your own servers or using a third party data centre that your vendor may recommend (or your own IT department). If you have no access to the software, however, you also have no option to verify any claims yourself and must rely on compliance certification and third parties to do this for you.
Nick Brookes (who writes on DAM technical/implementation topics) and I have recently been working with a client who are moving their own marketing oriented internal DAM to an external AWS (Amazon Web Services) server. The IT department require a SAS 70 compliance certificate. This involved no small amount of internal bureaucracy as the client is a large corporation where doing anything takes days of effort and multiple levels of authorisation. Amazon also require an NDA before they will agree to hand these over. Ironically, here’s another Gartner article where they doubt the value of SAS 70 compliance anyway:
“Gartner analysts said SAS 70 is too often treated by vendors and their customers as a certification “proving” security and compliance with privacy or other regulations that require enterprises to monitor their exposure to vendor risks. ‘SAS 70 is basically an expensive auditing process to support compliance with financial reporting rules like the Sarbanes-Oxley Act (SOX),” said French Caldwell, research vice president at Gartner. “Chief information security officers (CISOs), compliance and risk managers, vendor managers, procurement professionals, and others involved in the purchase or sale of IT services and software need to recognize that SAS 70 is not a security, continuity or privacy compliance standard.” [Read More]
Granted, the first point from Gartner (in the WebDAM article) does not preclude the second being correct, but the implicit assumption that the platform is secure just because lots of other people have put their trust in it is reminiscent of the sub-prime loan crisis in financial services a few years ago where there was a disconnect between all the different parties and everyone else assumed each other had been carrying out all the necessary lender checks – then found out they had not when it was far too late for anything to be done. As recently as four months ago, DropBox, which is still widely used by many as a ‘drive by DAM’ system is being described as the problem child of cloud security because of the various security incidents which have affected it, not least of which was when they claimed to be encrypting data but subsequently were proved not to be.
So far, Amazon have not yet suffered the same fate, but they have had several outages where design flaws in their EBS storage system were revealed (and did cause actual lost data for cloud vendors who had not backed up adequately in multiple regions). All these incidents make buyers wonder whether they can take Cloud providers claims at face value (and their reseller vendor partners too).
I would need to say, I’ve seen a number of Cloud or SaaS DAM applications (including WebDAM) and quite a few are reasonable products as examples of DAM software, but I have reservations about any product where you do not get a choice about whether you want to host it or use the vendor and you can’t see their product to know how they have chosen to implement a given feature. It’s not sufficient to be able to just take it on trust that a Cloud vendor meets all the security criteria required of them (and will continue to remain so – even after launch). Software companies get bought and sold with personnel changing constantly so it’s hard to have any certainty that the people who have diligently maintained and prepared the virtual infrastructure one year are still in charge of the ship in another. I personally have more confidence about recommending a product where the end user has the option to cancel a hosting agreement and host the software themselves if they so wish.
Since mid-2011, I have noticed a trend where IT managers will want to take on a DAM system but host themselves using a Cloud provider like Amazon, taking the advantages of on-premise but with the scalability of the Cloud (which is an undeniable benefit). Initially this seemed to be with open source products, but now I see it with all kinds of different licence options and the vendors being requested to either deploy it to a Cloud hosting provider or provide instructions to let the IT people do it themselves.
This ‘having their cake and eating it’ preference (as one disgruntled SaaS DAM vendor put it to me) seems quite likely to be a popular trend and while marketing departments have often bought DAM systems independently of their IT colleagues in the past, the increased popularity of DAM means it is no longer some ‘photo library system’ which they are likely to just ignore and let marketing departments get on with it. In part, this trend is being driven by security fears about Cloud hosting which the industry are not doing much to assuage. IT managers seem to mind less if they can actually get at the product and maintain it themselves. While their role also might well diminish, I predict a lot more demand for this ‘cherry picked’ approach to hosting, support and enhancement of DAM systems in the future.Share this Article:
Nice analysis, Naresh. I find it interesting how companies position themselves on either side of the “Cloud security” fascination. To me, we hear “news” about Amazon and Dropbox failures because they are, in fact, still newsworthy. If they happened all the time, no one would mention it. Counter this to what must be countless examples every day of on-premise systems that are compromised simply because the admin didn’t install some update, or the permissions configuration was so convoluted, that the system was easier to hack than to secure.
The only truly hack-safe computer system is one that’s turned off. Short of that, companies need to accept that breaches occur. You do what you can to avoid them, but it’s always good to have a plan in place to recover from one.
Picturepark did a webinar a while back that spoke to the advantages of Cloud vs. Onsite. I think it’s a valuable resource because Picturepark DAM software is available as SaaS or installed software, so we have no specific agenda in this regard. The webinar can be viewed for free (and without signup forms) at http://w4.picturepark.com/resources/webinars/dam-shootout-cloud-saas-vs-onsite/
I was the main inspiration for Naresh’s article and it was just timing and workload that meant he was able to write it up.
I think you’re probably right that Cloud hosting is not necessarily any less secure or prone to outages. It’s more that you don’t have many alternative options with it if you decide you want to host elsewhere if you take up SaaS.
I’ve generally found Amazon fairly robust and failure proof – but I’ve also seen some engineers set up Cloud servers very badly and left the applications hosted on them in an unstable and insecure state, even though they look okay to the end users. There are many configuration options and it’s becoming a lot less like conventional physical host management.
Maybe more people won’t care very much about it soon, but I’m from that generation of engineers that needs to be able to install an application from scratch before I fully trust it. I can live without the code, but putting irreplaceable digital assets into a black hole somewhere on the internet and hoping you will be able to get them back one day is still too much of a leap of faith for me to be comfortable with.
Thanks for your coverage. However, I too take issue with some of your points.
“The implicit assumption that the platform is secure just because lots of other people have put their trust in it is reminiscent of the sub-prime loan crisis.”
I think an essential point is missed here. Evaluation of a potential vendor’s customer list is in fact a very good indicator of their in-house security policies. Should it be the only indicator? Obviously not. However, about 25% of the enterprises we work with provide extensive security evaluations, often 10+ pages long, as a required step in selecting a vendor. Many organizations often run their own independent security audits, further validating the security of our infrastructure. This isn’t unique to WebDAM or meant to be a plug, only to illustrate that working with large enterprises means you are put through the security ringer at a level most internal IT projects are never subjected to. Further, each internal IT team has their own security policies and requirements around data security. This evaluation process means we have to harden the platform at the highest level of security policies and standards, which provides benefits to all customers not just one. And last, to another commenter’s point, there can always be potential breaches (how often do you install Windows security patches?), but the benefit of cloud companies is that they are constantly under evaluation and the aforementioned audits which means they are under much greater pressure to stay up-to-date with security.
“If you have no access to the software, however, you also have no option to verify any claims yourself and must rely on compliance certification and third parties to do this for you.”
By no access to the software, do you mean the source code? If this is the case, then I suppose only open source is considered “secure” in your book, which is a scary thought. Compiled software (typical for on-premise installs) does not usually grant you access to the source code either. Further, as a software engineer with 15+ years’ experience, I am confused as to how having access to the software helps you assess the security of the platform (servers, firewalls, software, etc). Or, are you referring to access to where the software is installed? Still though, I don’t see how that has helped you with security audits, assuming you have conducted them as an industry consultant. With any web exposed systems (as they pretty much all are today, on-premise, cloud, hybrid or whatever approach), the security tests and audits are conducted in the same way (using sql injection, cross side scripting and the plethora of other web vulnerability tests, none of which requires direct software access) and all vendors should be following OWASP top 10 guidelines. The difference however with on-premise installs is that in my experience, they are painfully outdated due to the overhead in pushing updates, therefore lacking the latest patches and security guidelines for today’s standards and expectations. Installing a third party application on your own instance of Amazon doesn’t guarantee any additional level of security, as implied.
“I have reservations about any product where you do not get a choice about whether you want to host it or use the vendor and you can’t see their product to know how they have chosen to implement a given feature.”
I hadn’t realized we were back in 1999, but let me try and address. First, please elaborate as to how you would assess the implementation of a given feature if provided the opportunity, as I am trying to imagine a world where IT spends time digging into third-party code just to see how features have been implemented? (FYI – I return to the point that on-premise is often compiled code and you can’t see how these features have been implemented either). Security teams don’t even assess application security by reviewing lines of code. I think you are missing the entire concept of abstraction. Abstraction allows us to build on top of already proven technologies. If we all spent time digging into code to validate it, we would all lose in the way of lack of innovation. For example, how does your bank conduct online banking? Do you spend your time digging into their code before entrusting them with your financials? Likely not.
The cloud has revolutionized many industries by allowing businesses to not have to worry about mundane details and (to be cliché) focus on what they do best. It has accelerated innovation in ways we could have never imagined. Does that mean we should use blind faith in trusting cloud applications (or vendors)? Absolutely, not. I couldn’t agree more. However, thankfully most organizations do opt for innovation over an out-of-date misconception of control and security.
As explained to David, Naresh’s article was mostly written from notes I prepared for him as I was originally going to write it, so, I’m the person who will respond.
“Evaluation of a potential vendor’s customer list is in fact a very good indicator of their in-house security policies.”
I can’t really agree with that. Before I got involved with DAM, I worked for the IT departments of several investment banks in the City of London and I’ve seen some truly shocking practices by both colleagues and external suppliers alike, even though there were supposed to be audits to stop this happening. As the Gartner report said, you can’t use SAS-70 compliance as an assurance that the environment is secure.
Following David’s point, hosting in-house doesn’t mean it’s any more secure, but as I mentioned, it’s about being able to host elsewhere if you want to and having the option to test it within your environment even if you don’t use it for production. On many occasions, I would recommend to our clients hosting with the vendor as they often do a better job of managing their own applications, but the choice element is essential in my view.
The Dropbox example is a case in point. They told users they were encrypting their data and later were proven to be lying. If you can’t see what the vendor is doing, you just have to take it on trust. This isn’t good enough and neither is the requirement to read the small print disclaimers on Cloud audit reports where they duck any responsibility if there is a problem.
“By no access to the software, do you mean the source code? If this is the case, then I suppose only open source is considered “secure” in your book, which is a scary thought. ”
That is a misrepresentation of what the article said – source code is not mentioned once, you have assumed that. Further, in the comment above in response to David, I said: “I can live without the code”. It’s possible to see what the application is doing when it stores metadata and user settings in the database, whether it really encrypts sensitive data all without access to the code. The issue, is being able to see what the application is doing with your data so you can audit and validate it at a time and venue of your choice.
You have to ask why a vendor insists on making you host the application with them. Most software businesses want to sell product to as wide range of customers as they can. If the vendor doesn’t want to supply you a copy you can host yourself that might be for many reasons. It could be that the software is complex to set up and it’s uneconomic to provide support for it. It could also imply that they have something unpleasant to hide they don’t want you to see.
“I hadn’t realized we were back in 1999,”
I don’t understand what you mean by this remark? As discussed, I did not say the code is required nor that IT departments will need to spend time ‘digging into it’.
I think you’ve missed an essential point with this article, we’re not saying the Cloud is bad or insecure, just that you need greater transparency than what most SaaS providers will offer you right now.
The clue about the theme of the article, is in the title. There are a lot of prospective enterprise software users now (DAM included) that now want the scalability of the cloud which SaaS vendors can offer but they also want to continue to manage a virtualised private cloud infrastructure so they can see what is going on; they want to have their cake and eat it too.
I think the bigger point that most of these debates miss is that, for a number of customers, Cloud vs. onsite *isn’t* actually a choice. I write about this in DAM Survival Guide. For many organizations, regulations, bandwidth, budgets and other factors make the decision for them.
Example: Northern Arizona University here in the US had the option of choosing Picturepark Cloud (SaaS) or Picturepark Onsite: it’s exactly the same software so, in theory, there was a choice to be made. But for them, the fact that they had money one year, but knew that money might not be there in later years, made the decision for them; They bought the onsite license because it required no ongoing payment.
Likewise, many customers are based in countries that regulate where data can be stored. In these cases, Cloud options might not be options at all. (This was one of the reasons that Cloud-based Picturepark was later made available on-premise too.)
For me, I can’t even begin to choose a side when it comes to things like security. The entirety of my personal wealth is accessible via Cloud-based application. (Well, except for the $5 currently in my wallet.) So, really, I have to trust the technology. And while I appreciate the value in “holding” the software in one’s hands (half our customers do exactly this), I’ve seen more than a decade’s worth of on-premise DAM installations that were far from secure simply because the systems were so overly complicated that few people could properly configure them.
Personally, I the Cloud vs. onsite/on-premise debate has become the Mac vs. Windows debate for a new generation. But there are far more important things for prospects to consider before purchasing DAM. That’s, in part, what DAM Survival Guide is all about, but it’s also what I tried to get across in this article: