Slashdot Mirror
How Would You Prefer To Send Sensitive Data?
sprkltgr writes "Our HR department is implementing new software. The HR Director has tasked me with sending our data out of our network to the consultant that's loading it in to the new package. Obviously this data includes items such as SSN, name, birth date, etc. Upon being told that I would not email this data to her, the consultant asked what my security requirements were for sending the data. What would be on your wishlist for the best way to send sensitive data to someone outside your firewall?"
Take some of those fur-lined handcuffs too. Do it on a Friday and get the weekend.
Engineering is the art of compromise.
Seriously --- why not? Stick the data into a truecrypt volumne on a USB thumb drive (or USB hard drive, for big data). If the contractor is nearby, walk over and type the password in yourself. If not, courier it and use encrypted email to transmit the password (or just tell the guy over the phone).
Repton.
They say that only an experienced wizard can do the tengu shuffle.
- That local users would create decent passwords
- That remote users would be able to understand how to decrypt/open the documents
- That users wouldn't send the password in the same email as the encrypted file
The found marginal success with Office document encryption, but ultimately, things were nearly impossible to audit when people were doing their own encryption.We put a PGP Universal server with web messenger between our internal mailserver and our SMTP gateway, and set policies on what does and doesn't get secured. Aside from the occasional external user who is baffled by the concept of creating a passphrase, the server has been trouble-free. If you have to deal with arbitrary external mail recipients with unknown levels of clue, I highly recommend picking either PGP Universal or Tumbleweed.
ResidntGeek
You've also got to remember that you only have control over the security of the data during transit. It's all you're legally responsible for and it's all you have any sort of effective control over. So you're really looking for the best solution based on the transmission type you choose. For anyone who wants to put all sorts of extra security on it remember the thing problem with copy protection you can't secure something and give people the access to view it at the same time, so if the recipient doesn't secure it properly in their system, no amount of PGP is going to help anyone.
If the data set is fairly small, then encrypted e-mail might be a valid solution. If it's small to middling in size or you need to do frequent transfers SFTP or FTPS would be viable(presuming you're not using keys generated in the last two years on a debian box).
The simplest solution would be to encrypt the data, put it on a CD/DVD/Portable HD, and send it by courier or deliver it yourself(ideally in a sealed envelope). You get a signature to verify you sent it, you get a signature to verify who picked it up, you've got proof it wasn't tampered with and if someone steals it along the way it's not worth anything.
If it were me I'd also ensure that your contract with the recipient includes liability for any security breaches within their system including appropriate financial penalties. Any of those solutions will ensure it gets to the recipient without someone else stealing it and that's all you can do.
The unencrypted FTP traffic on the far side of the VPN connection can be sniffed. Passwords should never, never, never be sent in the clear, even over a local network, because people are awful about change passwords and will use the same one in multiple locations. And if the VPN is between two networks, rather than between your machine and a remote network, the FTP traffic an be sniffed inside your own network.
It only takes one compromised laptop in most networks to engage in quite a bit of useful packet sniffing of exactly this kind of traffic. Unless that VPN is between your desktopo and the VPN server itself, it's hazardous.
You keep saying that. Maybe you want to run the numbers sometime? Something like all the computing power in the world in constant use for X thousand years? Barring a fundamental flaw in the algorithm, or a botchy implementation (say generating your keys on Debian) there is no way this is brute forcable in anyones lifetime. It's just math. It's your random claim the russian maffia can break any encryption, versus math. I know whose side I am on.
Half a million bucks buys you a 56 bit DES message in under 24 hours. Note that an extra bit does not double the effort, it squares it. Do the math.
Really, what's wrong with just using IPSEC and ftp? ftp is canned crap by itself because of the stupid networking requirements (if you're already using TCP, there's no reason WHATSOEVER to open two connections, much less to do it how ftp does) and generally impossible to secure through rational means but is fine through VPN.
Of course, you have to make sure that your switch isn't vulnerable to a poisoning attack that will let a local attacker sniff that password, unless you do direct host to host ipsec, which is my recommendation anyway. Then the whole thing is pretty secure. ipsec is relatively easy to set up on windows with preshared keys (I never did get certs to work between HPUX and Windows which is where I tried it, but if I'd had a Windows 2003 domain server it supposedly would have been easy) and plenty easy to set up on most Unices.
Alternatively, just put a simple password on the thing, USPS the password to the guy via some kind of registered mail, and then courier the data, and do it physically. This is much more secure, provided your carrier is competent. (Read: NOT UPS, who not long ago delivered eight pounds of court documents to me at 9850 on one street, while it was addressed to 9580 on another street.
"You're right," Fisheye says. "I should have set it on 'whip' or 'chop.'"