The company I work for is extremely risk averse when it comes to adopting the use of cloud services for improving business flows.

We currently use a very famous search company's business back end for a lot of our infrastructure. That means we automatically get their cloud storage and document sharing services.

The company has a process where they proof digital documents. The documents are created by a third party, burned to a physical CD and sent via registered US mail. This not only slows down the business process, but I feel that this is equally if not more insecure than utilizing the cloud storage service we have access to. For example, if someone with bad intentions got a hold of this physical media they would have all the time in the world to try and crack it or even duplicate it (data application for Law #3 of the 10 Immutable Laws of Security).

Additionally, the files on this disk are probably not being encrypted, but being placed in a password protected zip file.

I am making a comparative write up (with references) on the insecurities of sending these digital documents via the US postal service as opposed to using a cloud sharing option.

What are the risks of sending sensitive digital documents that are on physical media and password protected via postal carrier using registered mail?

This is really just about the risks of sending data on physical media and not about the encryption scheme of the data.

  • I think the answer to your question depends on (a) what kind of encryption do you use, and (b) how do you transmit the key?
    – Anders
    Commented May 11, 2016 at 14:53
  • @Anders My assumption is, the files aren't being encrypted, but are being archived in a password protected zip. Commented May 11, 2016 at 14:55
  • Ah. I would recommend you to edit your question so it includes that information. Also, this might be an interesting read: security.stackexchange.com/questions/35818/…
    – Anders
    Commented May 11, 2016 at 14:59
  • 1
    Well the Equation Group has been known to intercept physical media and put malware on it: kaspersky.com/about/news/virus/2015/…
    – AstroDan
    Commented May 11, 2016 at 15:51
  • Well, according to Wikipedia, registered mail may be used to send "SECRET" classified data, it's gonna be quite hard to establish a procedure that is more secure
    – SEJPM
    Commented May 11, 2016 at 18:46

2 Answers 2


There are always risk, the ones you are asking about have more to do with physical access and physical loss of the media. As many others have mentioned encryption is going to play a big part in helping with your solution.

I'd recommend taking a step back and looking at the specific risks that concern your business and this data in particular then creating security controls & countermeasures to handle each specific risk.

Some businesses may not care if a copy of the data sent is stolen as long as at least one copy arrives within a reasonable time. This is more of an Availability issue.

Some business are ok if any given copy of the data sent never arrives as long as that data cannot be read by anyone outside of their organization. This is more of a Confidentiality issue.

Other businesses are very concerned about the data and transport media they are using being tampered with or modified in some way. This is more of an Integrity issue.

For any given business shipping data for a given project the Confidentiality, Integrity, and Availability needs are all going to be a little different. My point here is that you need to address each of these components of the risk separately.

There are additional variables to each of the following but in general you would be wise to address the following separately:

For confidentiality encryption is going to be the no-brainer. You will want to use very strong encryption and enforce very strict key management.

For availability you may want to ship identical packages via multiple carriers. This is a cost issue more than anything and in most, but not all, countries this one might be easier to solve.

For integrity you may want to consider how you contain the data in transit to prevent tampering. Part of this has to do with which media you use, specifically the size component. This may also affect shipping costs but you can leverage a wide array of physical security mechanisms and anti-tamper mechanisms to prevent tampering. Whether this is the super-cheap "glitter nail-polish" to seal a box method or you end up shipping a small bomb-proof, fire-proof, water-proof safe containing custom-built evidence bags with your signature all over it and cover that with custom hologram seal tape and maybe work 5 other unique things into the packaging (you get the idea).

Now that you've looked at these components separately you can look at the situation again and weigh the value of the data, the costs of potential solutions, and figure out what is the best solution based on your needs.

Do go for maximizing low-cost solutions but avoid low-quality ones. Strong-encryption is a HUGE win. Tamper-proof evidence bags are cheap and if availability is an issue find the cheapest way to ship things. The more cost-efficient your security solution is the longer it will last. Likewise this free's up your budget for other security tasks.

Task specific to your question that I would recommend. Figure out how to make strong encryption super easy for the people using it. Don't just trust the .zip file passwords. Find software where it's a "right-click" or "command-click" and it's encrypted level of ease. Likewise force the people receiving packages to notify you if anything ever arrives which is not encrypted. It may even be worth having the people who encrypt it not be the people who check that it's encrypted and ship it (separation of duties). Again it's really important to keep everything simple and easy if you want your users to do the right thing.


Look at the chain of custody. At the point of origin, you have a client; the client has a computer with a secret document, a ZIP program on it, and a secret password. At the point of receipt, you will accept the ZIP file, decrypt it with the secret password, and process it.

We can assume that you and your clients are equally susceptible to attack at the end-points regardless of whether the file is carried on a disc or uploaded to the cloud. If the attacker has a keylogger or other malware on the client's machine, it hardly matters how well the data is secured.

Modern Windows ZIP utilities (WinZIP, 7-Zip) use AES-128 or AES-256 with a password derived key; this is very strong encryption. (They also offer backward compatible "ZIP 2.0 encryption", which is not secure.) The security of the encrypted data will depend entirely on the security of the password chosen. With sufficient notice to your clients, you can choose to not accept files that aren't properly encrypted.

IFF your clients use a secure password, and IFF they properly manage the password, there is no relevant security difference between the postal service and a cloud provider. In neither case is a man-in-the-middle attacker going to be able to recover the data without the ZIP password. But that's a very big IFF. You are not in control of your clients, so you cannot specify exactly what kind of security practices they will follow.

A postal service CD is more difficult for a remote attacker to intercept than a file on a server. An attack on physical media requires physical presence, something a remote hacker generally will not have. But if they do have physical access, there are many points where the disk could easily be intercepted and copied. Then, the only security you have is with the ZIP file encryption. The attacker will need both physical access to the CD and a copy of the secret password.

Cloud storage requires its own set of access mechanisms, such as passwords or certificates; which are something additional that both you and your clients need to securely manage. You may still require the ZIP file to be encrypted using a secure password (this is actually a rather common requirement.) But you each now have several sets of credentials to maintain, and this is where humans really fall down on the job. Ask them to do too much and they get confused; they may send the file unencrypted because the cloud server has a password, or they may accidentally share the upload password instead of the ZIP password. Remember, you may be tech savvy, but not all of your clients are: your clients may have completely non-technical administrative people trying to upload the data, people who will make mistakes.

If your cloud client makes two mistakes, revealing both the secret password and the cloud credentials, the attacker can win. This can be mitigated even further by use of two-factor authentication; it exacerbates the complications further, but it will help stop any cloud server mistake from spreading.

If your postal client makes one mistake, AND the attacker has physical access, the attacker can win. In this case, the client has to reveal the secret password to an unauthorized person; but social engineers are really quite good at getting this info. I wouldn't underestimate that threat.

Finally, like it or not, success will depend on how everyone feels about the cloud. If your chief security officer says "I don't trust the cloud", then all you can do by pushing harder for a cloud-based solution is to get yourself in trouble. If your marketing people tell you "my clients don't want all that security stuff", do not force your opinions on them. Telling them scare stories about CD thefts will just serve to spook them in general. When you spook your clients you risk them running away, and with no clients you have no money and no job.

You may be much better off keeping the solution in your pocket, or silently getting an implementation ready. That way when your clients say "we need faster turnaround time than this CD-in-the-mail thing", you're ready with a faster solution. But there does not appear to be a compelling need for you to change how your clients do business today, so don't force it.

You must log in to answer this question.

Not the answer you're looking for? Browse other questions tagged .