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.
If this is a manual task, and you are on a *.nix box or similar (OSX too), just use scp (Secure CoPy). If there are lots of files, package them first to make things easy (tar.gz or .zip or whatever), and just scp the file to the other computer. It takes the same parameters as ssh and uses ssh but was designed to just send files securely.
With scripting languages you can also automate this process.
- 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.
encrypted thumb drive.
use truecrypt and create an encrypted file on a thumb drive. then if it gets lost, no one can retrieve it.
They're using their grammar skills there.
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.
If you're sending data to a consultant for processing, how do you expect the consultant to return the finished product to you? You can be as paranoid as you want and totally ineffective if next week the consultant emails you an unencrypted MDB file.
The other replies make a lot of sense in pointing out that your security policy is only as strong as the consultant's weakest link. Can someone potentially sniff the email as it goes by? Sure. Is anyone actually watching? Probably not.
PGP or GPG keys sent via email are always vulnerable to "man in the middle" attacks unless you verify the fingerprints through other secure channels, etc and so forth. Is anyone taking the trouble to do that for access to your data? No. Seriously.
You could probably even get away with putting all the data into a single ZIP file, and then putting THAT single ZIP file into a password protected ZIP file. (If you have more than a few files in a password protected ZIP file, there are apps out there that can do some comparisons and crack them open in moments.) One file in a ZIP, with a strong password given over the phone, should keep out the nosy and all but the more educated hackers. The educated hacker already has access to your system after asking HR's password on a "support" call.
I'd agree with the masses - GPG. However, it is VITAL that the consultant knows to encrypt the data sent BACK or it is just a waste of time. Good luck!
Help! Help! I'm being repressed!
I have worked for two different companies that sent ACH (EFT) type transactions worth tens of millions of dollars over the internet. We used an SSL HTTP web site for the transfers, and encrypted AND signed the packets with PGP keys. That way, when we got the packet, we could decrypt it AND verify the originator.
... sorry.) And unencrypted data was never allowed in the DMZ. I'm not sure how long unencrypted data may have been on app servers or in memory, but I remember security and the developers having a lot of conversations about it.
.. don't stop at just the transmission. Security has to be looked at from source to destination and archival.
I'm sure if someone worked hard enough they could have broken it, but since the firewall would only allow connections from specific IPs, it would have been tough to inject data into the system.
This meant that the biggest threat wasn't someone stealing the raw data, but someone on the inside gaining access to the data after it was processed or was being processed and possibly in an unencrypted state. The DBA used some type of Oracle encryption to prevent someone gaining access to the database and being able to run SQL queries and return unencrypted data without some type of key (I don't know how it worked
So
I rarely read replies, it's my opinion and if you thought about your opinion a little more, I'm OK with that.
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.'"