For a number of months, I have been working with a client on assessing risks to their digital assets stored inside and outside their DAM system. The motivation for their interest was sparked due to some naive data management policies where sensitive asset files were held without any security or backup. Originally the data was not particularly important and the risks gradually increased from what they once were. This data security scope creep seems to be a common feature in many enterprises.
Being involved in audits of data security, even at a relatively non-technical strategic level, reveals some hair-raising data safety practices, even among those who should know better. Many of these are fortunately relatively easy to rectify with some best practice guidelines, staff training and a moderate amount of peer group pressure from co-workers. A more serious risk is emerging where data is wilfully being kidnapped and then held to ransom. This seems to take two forms at present: liquidator retention and illegal encryption of data using viruses. A third more direct targeted attack is emerging (which I shall discuss below).
Unauthorised liquidator retention is where data was held with a once-reputable service provider who have since got into financial problems. A liquidator (or new owners of a failed business in some cases) then demands cash from existing customers before they can get their data back. My co-contributor, Nick Brookes, reported on this last year with reference to failed data centre provider, 2e2. I do not know how legally watertight their actions are, but it does seem an obvious ploy that a liquidator might use to extract funds from customers to pay off creditors.
The second: illegal encryption of data using viruses is a lot more worrying. Many readers will be aware of the Cryptolocker trojan that appeared late last year. Once a computer is infected, it encrypts data (including files on shared network drives) using a key which is virtually impossible to break. The user is then informed that their data is locked and offered the opportunity to buy a decryption key to release their data. The purchase is required to be made using a hard to trace payment method (such as bitcoins etc). So far, these trojans have been restricted to Windows computers, although since many Mac users are creatives who hold important digital assets like photos and design files and so on, it seems unlikely that it will be too long before the criminal gangs who have developed this type of malware decide to target that market also as they are even more likely to pay the ransom.
There is both an opportunity and a threat for DAM vendors (especially Cloud or SaaS providers). The obvious opportunity is that a remotely hosted DAM provides some protection against encryption trojans since it is virtually impossible for them to access files stored remotely on the DAM vendor’s servers. The threat is two-fold. Firstly, there is the possible risk that if the SaaS vendor uses a data centre provider who get into financial problems, they can find themselves (and all their customers) in the same situation as those of 2e2 last year. Secondly, there is the risk that the vendor’s own servers will become infected with encryption malware, kidnapping all their client data in the process. For those SaaS vendors that utilise UNIX or Linux servers then the threat is diminished since they have not yet been deemed a large enough group of users to be worth targeting (yet).
A more worrying trend I have discussed with some experts in IT and data security circles is where the criminals target specific companies with the intention of capturing their data and then extorting money from them on a case-by-case basis. The ransom fee is also much larger to reflect the effort the crooks have to go through (and the revenue opportunity for them). Most SaaS software providers, especially DAM vendors would face potential litigation followed by bankruptcy if client data was appropriated in this fashion. One imagines that many would decide to both pay up and shut up about such an event as even if they paid the ransom and recovered their data, the PR impact could be devastating. The technology the vendor uses is not as relevant in these scenarios since any data kidnap attempt is more likely to be custom-designed and adapted to suit. In some ways, the larger or better known vendors are at greater risk because of their more visible presence to would be attackers.
As we have described on DAM News before, if a SaaS DAM vendor won’t give you the opportunity to download your own backups of your assets (and preferably metadata also) then that should be a deal-breaker. It is essential to be able to organise your own replicated off-server data storage if you want to and therefore mitigate data kidnap risks without relying exclusively on the vendor alone. Even if you audit them regularly, that still isn’t the same as having copies of the digital asset files safely stored on your premises should an incident occur.
I gather that some vendors make use of services like Amazon’s S3 (and possibly Glacier) or Code 42’s CrashPlan plus a number of others from Microsoft, Google and various independent specialists. If the vendor allows you access to those backups, that is an option also, but whatever service offered, it must support full versioning so you can retrieve older editions of any files that might have been compromised. My co-contributor, Nick Brookes also believes that being able to download your own copies over a secure connection as well as those options is necessary (and I would agree with him). That old IT maxim that you can never have too many backups is worryingly accurate in today’s hostile data security climate.
Unfortunately, I believe we will see data kidnap and ransom becoming increasingly prevalent and more criminals seeing this as an easy way to extort money from end users. Sadly, Digital Asset Management is a high risk target because of the nature of the service provided. The best defence is to prepare for the possibility of it and develop plans to reduce the impact if it does happen to you – or the DAM vendor you use.