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.
How about SCP over SSH? As far as I know that's quite secure and I can tell you from experience that it's damned easy to set up and use.
ResidntGeek
I see a lot posts suggesting you mail or hand-deliver the files on disk. In my experience more data is leaked through lost mail and courier mistakes than by hackers.
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 would use Protectoria they provide a safe way to send sensitive information via e-mail without any initial setup
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.
Don't move the data, move the consultant. Prepare a work space and ask the consultants to work in your office. As soon as data leaves your system you have no guarantee that it will not be passed on. Data transfer is the least of your problems.
Additional issue: Sending raw data out is easy (many ideas have been voiced in this forum) but how are you getting it back? Tables to import? Live link between your company and the consultants? Incremental? Is this a one-off or a continuing effort?
Regards, Oliver
Secure VPN tunnel and some form of remote desktop if it's GUI based,or SSH in if it's terminal based.
In a world of highspeed connections and cheap hardware there's no excuse for anything to leave the confines of your network where you as the person in charge of security remain the person in charge of the security.
IF (big IF) you can trust the outside network with the data, which I would consider to NOT be true in 99% of the cases, you could implement what I laid out on one of my sites. Check out http://cryptmsg.com
Completely open source, implement as you'd like.
Basically, you give them multiple keys, each by different methods (phone, fax, in person, postal mail, IM, etc), and you select the encryption methods. You encrypt the message on an off-line machine, and pass it to an online machine for delivery. The encrypted message goes out through any unsecured channel (i.e., email). They decrypt on their offline machine and now they have the message. All in all, it could be an easy and secure system. Since my code is open source, you can rehash it any way you'd like.
This is pretty much what I wrote it for. Secure, unbreakable transmissions over unsecure networks, where it's a given that someone will intercept it.
I include an encrypted message in my tagline. I'll Paypal $10 to the first person who cracks it.
My biggest concern would be that they're reading it on a machine that has Internet access. You can secure your servers like Fort Knox, but we all know perfectly well that every foreign machine is suspect. That's a risk you have to be willing to take.
I've seen sites that provide "secure" data on demand to authenticated users, over SSL via their web browser. You can key it to the end user's IP, and require a user:pass, but there's still potential for abuse.
If your information is that sensitive, you should only allow access:
1) If they are on the secure portion of your network
2) That part of the network does not have Internet access
3) You have a strong security policy for that part of the network
4) You have a strong security policy for the workstations on that part of the network.
Since that doesn't usually fly in the business world, you'll have to make the exceptions, which you're asking about. Make sure you have upper management approval in writing for the exceptions that you are going to make, so when it hits the fan, you are not the responsible party.
Serious? Seriousness is well above my pay grade.
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.
No seriously. Not 'Funny', but 'Insightful'. If you care at all about security, you do not send your sensitive data over a hostile network. In fact, the data should never even be accessible from a hostile network.
Minimum security in this case would be to require the receiver of the data to work with the data on a computer which is not connected to a network, because once malware infects their network no amount of encryption will keep the data safe.
Put the data on physical media and have it delivered by a security company that does transport of valuables.
Now if you were SERIOUS about the security, what I've mentioned previously being only minimum security, you would further require physical security at the receiver's location. Not just the security that placates insurance companies, but the kind that aims to actually PREVENT theft.
All rites reversed 2010
to be honest, if you are truely concerned about the security of everyone's SSNs and personal information, you can always turn to an archaic form of secure correspondance: certified mail. every person who handles certified mail must sign for it in ink, and it is a Federal Felony to lose/misplace/steal certified mail. Dont quote me on this, but I think the US military has approved certified mail as one medium of transporting items labeled "SECRET". Given this method will take more time, but the end result will be probably the best solution to security of the data in transit. if you hate the consultant, print off the data and mail it to him, and if ya wanna be nice, just toss a CD in mail.
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.'"
http://www.7-zip.org/
Three years ago I would have said PGP. Today I'd email this using Zixmail encrypted email if the file size was under 5MB. If the file was over 5MB I'd zip the data with Winzip to an AES256 encrypted file, burn it to a CD/DVD, send it via courier by Fedex/USPS/UPS/etc, and send the encryption password out of band via email or phone.
Duris MUD - The best pkill MUD. Ever.
Just zip it all up and password protect it, come on!
-ducks-
Flappinbooger isn't my real name
Just follow UK government standards and write all the data on a CD or two then stuff them in the regular mail.
Honestly, what could possibly go wrong?