Secure Shipping of Physical Data Carriers to and from a Cloud Service Provider
A cloud environment is ideally suited to store and analyze large amounts of data. If more storage space, CPU or memory resources are needed, services can usually be upgraded with ease. This situation is likely to occur because data tends to grow over time. This data could, for instance, be a sales database, ingesting logs from an e-commerce platform. The data could also be made up of security logs, collected by a Syslog server or a SIEM such as ArcSight or Splunk. In any case, usually, this data will be generated over time, inside the same cloud platform that it is stored and analyzed in. There might also be a feed of data originating from an external, on-premises system, uploaded in real-time or in scheduled batches. What if the data is too large to upload though? Imagine a cloud migration and the need to upload many Terabytes of historical logs onto the newly configured cloud environment? An upload would be too costly or would take too long. Also consider needing to obtain all that data from the cloud, for instance, because a customer is canceling their cloud service. What are the options and how is this data transport managed while adhering to the highest security standards?
Physical carrier shipping
Most Cloud providers such as Microsoft Azure and Amazon WS are more than happy to assist. They offer an address where customers can ship their data on physical disks, and their staff will then (usually for a fee of around $100 USD per disk) make that data available to the customer. The providers are also able to send exported data to the customer on physical disks. The details of these services vary for each Service Provider. Google Cloud, for instance, requires the use of several 3rd parties for the import and export of data, but the end-result will be the same for the customer. So far, no issues to be found. Cloud Service Providers have been handling these requests for years now.
For most organizations, their data is or should be, one of their most valuable assets. This might be the reason they decided to migrate to a cloud solution in the first place. What if these disks containing the many Terabytes of data go missing in transport on the way to or from the cloud provider? Imagine a 50TB database of sales records including PII and credit card information, being “unaccounted for.” Even though the disks might never end up with an entity with malicious intent at all, the organization would need to assume the worst; the data has been compromised. In most cases this will be disastrous, impacting a company’s reputation, compliance to regulations and of course the bottom-line.
Encryption seems to be the most logical security tool for this issue, but how would the Cloud Service Provider decrypt the data on their side, to make it accessible again once the disks have been received? This is why Cloud providers set some solid requirements. Again, the details vary.
Microsoft requires the customer to use their WAImportExport tool for the transfer to disk and to encrypt that data using BitLocker. The decryption key is then placed inside an import .csv job-file inside the Azure portal. This means the decryption key does not travel the same route as the physical disks, which would, of course, defeat the entire purpose of encryption.
Amazon requires the use of the AWS Import/Export Disk tool for the data and the creation of a job inside their portal. That job needs to contain the decryption key. Like the Microsoft solution, this ensures the disk and decryption key travel via a different route. For data exports, Amazon can either use hardware encryption, and a pin pad on the customers supplied storage device, or if this is not available, the default option is the use of TrueCrypt.
A secure carrier
As mentioned, Amazon supports the use of “Secure Hard Disks.” These disks encrypt data on the fly with algorithms up to the AES-256 standard and work via a password or physical pin pad, mounted on the disk itself. There are many such devices available, but they can be very costly relative to their size. Imagine needing to transport 25TB of data via very expensive 250GB disks. This is only an option for smaller amounts of data, which are just too much to directly upload via the internet. Placing larger, standard disks containing encrypted data, in a lockable container before transport might be a better solution.
Another option to consider is to use a secure courier service for the data transport. There are many providers of these services available, and the options range from businesses that only employ vetted staff, all the way up to the assignment of a dedicated door-to-door courier.
When planning to ship encrypted data internationally physically, it is very important to keep the current export and import regulations of the involved jurisdictions around cryptography in mind. Most of these regulations cover only the encryption tools, but some countries such as China and the Russian Federation prohibit the use of encrypted devices altogether. It is best to consult a legal expert on this issue because information is only scarcely available and mostly from unreliable and out of date sources. The last situation a company wants to find itself in is trying to retrieve a shipment of disks full of PII data from a foreign customs office after unintendedly breaking the law.
There are many options to get data to and from a cloud service provider via a physical carrier and most seem quite straightforward. It is important to take this serious, however. Not only could the loss or compromise of data during transport be devastating to an organization, but there are also many regulations in place that cover this type of transport and data handling. The issue is not so much around protecting the data from being compromised; it really is about guaranteeing the data has not been compromised when it arrives at its destination.
We've encountered a new and totally unexpected error.
Get instant boot camp pricing
A new tab for your requested boot camp pricing will open in 5 seconds. If it doesn't open, click here.