Does Your DAM Leak Data?

Recently, I have had cause to go through some prospective DAM solutions that clients have expressed an interest in and do some preliminary exercises with a view to shortlisting a few.  One of the requirements fairly high up on the list was security of their assets.  The client in question said they had an interest in a Cloud DAM (for various operational reasons) but their concern was with how secure they were.

I have a basic working knowledge of web application security best practices which (while not exactly exhaustive) is usually sufficient to top-slice away anything which doesn’t pass a few simple tests.  In the past, I have observed that some legacy DAM applications had some fairly serious security issues.  Most of these were early-stage web solutions where the developers implemented them that way because they probably didn’t know any better and general levels of awareness about web application security issues around a decade or so were not as good as they are now.

In 2016, however, most modern enterprise software tends to have some kind of browser UI and anyone who works in this type of field really has to have a level of understanding that covers the rudimentary issues and how they relate specifically to the class of system they work on.  There are numerous examples, but one which is key to Digital Asset Management is the presence of an asset/user security model which validates each request for an asset by a given user and rejects any where the individual lacks the requisite permissions.  This is fundamental to the security of DAM solutions and all multi-user DAM systems need to have implemented a model like this to meet the minimum criteria to be considered secure.

One product of those I was asked to look did not have this.  The user interface was very slick, had all the ‘glide and slide’ animations etc but no security model had been implemented.  There was a user ID and password, but they were only needed to get into the system, if you knew the location of the assets, you could get to them directly without logging in.  To make matters worse, the asset IDs were numeric.  Of itself, this wasn’t an issue, but it meant it was possible to flip through the entire catalogue by just incrementing the ID in the URL via the address bar of a browser.  This is the security equivalent of locking the front door to your house and leaving  the windows and garage door wide open.  Testing this is fairly easy for anyone to do without special tools etc, you can right-click (or control-click if you are a mac user) and copy the download link and then paste it into a different model of browser to the one you use to access the DAM.  So if you are on Chrome, then you paste the link into Firefox, Internet Explorer etc.  If you can still download a file without being given a user ID and password prompt then your DAM is not secure.

There are some mitigating factors and additional considerations with this test that it would be remiss not to mention.  A fair number of DAM vendors who use Cloud delivery methods now store digital asset binary essences (i.e. files) on a cloud storage service like Amazon S3 or Google Cloud etc.  I have described how these work in the past, the DAM system acts like a broker or intermediary to point you to the asset file when you request it.  I am not fully familiar with mechanics of these delivery systems, but one method which is popular is to provide a temporary link which will work for about 30 minutes and then a new URL has to be generated (which you can’t do if you’re not logged in).  This isn’t great if you have higher than average security requirements, but for standard materials (i.e. nothing sensitive where a brief ‘window’ of open access is acceptable) then it is probably a fair trade off.  The technology for this is implemented by the cloud provider and they tend to use hard-to-guess identifiers composed of hexadecimal strings (or numbers and letters between ‘a’ and ‘f’ for non-technical readers) that have the appearance of being randomly generated.  As such, if you’ve just found your current DAM system of choice looks like it will leak your data to anyone in the world, leave it an hour or two and then re-test prior to interrupting the start of your vendor account manager’s bank holiday weekend with a phone call or irate email about security practices (I’m sure everyone loves to get those kind of emails on a Friday afternoon).

Before the vendors reading this article breathe a sigh of relief, however, there are a few more twists to this plot.  As well as checking the asset binary essence itself, nearly all DAM systems worthy of the name also produce proxies, i.e. previews, thumbnails and other media for display purposes to help users decide if an asset is suitable before they download it.  In a few cases, especially where larger previews  are generated and certainly for videos (where higher quality protocols like H.264 tend to be the standard now) these are almost as good as the original asset in terms of legibility.  If the material is sensitive (e.g. previews of pages from documents etc) they could be sufficient for anyone who wanted to collect information to use for nefarious purposes at a later date.

In a further three of the applications I tested, while the asset files were secured with transient URLs, the previews were all persistently accessible without being logged in when tested (and still are as of today).  Granted, these weren’t easily guessable, but they did all use a form of identification that related to the asset ID itself.  These type of identifiers can often get included on metadata exports and other outputs which could be gleaned by someone who is determined enough.  To use my earlier metaphor, this is a kind of ‘key under the plant pot’ form of security – you have to guess the right one but a determined burglar probably will be motivated enough to try and do that.

I suspect these previews are not secured because they need to get used outside the DAM where the security isn’t enabled, but they do represent a potential risk and if you have higher than average security requirements (as my client did) then they are probably not a risk worth taking.  There are various alternatives including a hybrid of Cloud delivery and some more conventional methods where previews are not held on third party storage.  Another possibility is using different security models with some that have stricter rules than others for more sensitive assets.  These are all fairly technical in nature, however and outside the scope of this piece.  If this issue is important to you, it would be well worth having a look at how this is handled now and discussing options to tighten things up a bit more with your DAM vendor (if your system of choice currently exhibits these issues).

The final cloud security story I have about leaking data relates to an author whose book I bought about a year ago (unrelated to the DAM field, incidentally).  I searched for some information about this person via a search engine and found links to some files from his website that were stored on Amazon S3, in particular, one which was an index of every file he had uploaded – not just relating to his book but all kinds of other stuff too.  Accessing each of these was as simple as just copying and pasting the filenames into the browser.  The individual in question had uploaded some highly personal data which I am 100% certain he would not want complete strangers to be able to view.  Since you have to explicitly change settings to do this (because it is obviously quite risky and Amazon want to prevent people doing it by accident) I would guess this was an attempt to open up some files for other people to get access to which went wrong and instead he had revealed everything.  I emailed him and he thanked me and said he would get it looked into, that was about a year ago.  I can still gain access to this data today.

This is clearly amateur use of cloud storage facilities and a point that should get verified if you are using a commercial DAM, however (speaking from personal experience as having been one in the past) engineers and developers do frequently make basic mistakes for a variety of reasons and it should be part of the service delivery process to make sure that more than one person checks all these details and ensures that nothing get left open to the world.

I will make it plain, this is not just about Cloud DAM security.  The fact these examples are on a public network makes the issues more visible but I know they definitely happen with internally hosted DAMs too (in some cases they are worse because there is less scrutiny of them).  Just because it’s inside a corporate network doesn’t necessarily mean the consequences will not be as bad – especially if disgruntled ex-employees find they can still get their hands on materials which you don’t want them to.

If you have very high security requirements then as a general rule, DAM solutions might not always be the first choice as a class of products to use for this purpose.  With that said, it’s almost inevitable that sensitive assets will get uploaded to DAM systems either accidentally or because of a lack of a suitable alternative.  With that in mind, these are risk factors that should feature in every DAM initiative project manager’s risk analysis along with reasonably detailed and well-rehearsed plans to mitigate them.

 

Share this Article: