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?"
Why not some kind of secure FTP Server for her to download it?
Or if the area is not to far, why not burn it to a CD or some other kind of media and physically take it to her.
The greatest revenge in life is massive success.
If it's data to be processed and used with a database or something similar, then I'd suggest either SFTP or set up a site-to-site VPN between your 2 offices and either provide them with instructions for FTPing it off of your server or the other way around. A simple link would work as well: ftp://10.10.10.10/yourfile.csv that way it's almost dummy proof.
Correction: ftp://user:password@10.10.10.10/yourfile.csv is the proper example link.
Send all the data via FedEx on a CD, in an encrypted file. Send the password via e-mail.
Of course, this doesn't address the issues revolving around exposing all this data to your consultant to begin with.
Deliver the data by e-mail, but store it such that it's determined losing it does not present plausible risk. I mean what other options do you have? Authenticated download over SSL perhaps.
PGP maybe. Say we PGP encrypt an e-mail. We now rely on the secrecy of the recipient's private key. This means we rely on the recipient's security infrastructure to properly protect a piece of data until the data we transmit has become non-useful (this includes destroying all copies of the key -- when actually done, we guarantee the key remains secret forever). Can we trust this? Not really.
Well with SSL, the certificate gets verified against a CA signature. The client automatically establishes encryption in a secret way (randomly generated public key, sent to server, which sends a signed and encrypted session key) so we know no third party can eaves drop, without any infrastructure on the client end. Now, this is where I pull up Ettercap in the next hotel room over, and the client clicks "Accept certificate temporarily for this session" when it warns him my MitM cert is self-signed. Again, can't trust this.
Well, let's hand it off on a USB flash drive. Does he lose it? Leave it in his car? Hell, it's now on a storage system at another company with odd security practices. Again, out of your control.
All solutions suck. Transport isn't an issue, it's ensuring data confidentiality at the destination (including any encryption keys used to secure the transport, as well as the decrypted data itself once stored at the other end).
Support my political activism on Patreon.
gpg/pgp is great for the transfer... however once it's in the person's inbox, you have no idea what they're going to do with it.
Giving anyone other than my parents personal information about myself (credit card number/ SSN) over the phone pains me. It feels like I'm running a red light every time and I'd rather not do it.
...spike
Ewwwwww, coconut...
If you need to get on a VPN to access the FTP server you're already authenticated. There's no point in authenticating twice (unless you want different levels of access, or the FTP server is also accessible from other networks).
That and email just is not a good way to send lots of data, it just isn't designed for it.
I'm more in favor of setting up a VPN....and using scp across it.
That will work better for what I guess has to be a good bit of bulk of data...and should be quite secure enough.
Light travels faster than sound. This is why some people appear bright until you hear them speak.........
VPN access is per-machine. FTP access is per-user. Making it accessible to anyone on the VPN is equivalent to chmod'ing 777.
It's amazing how many people make this mistake. NEVER implement an unauthenticated protocol, unless you can completely guard access to it -- and by that, I mean use it over pipelines, UNIX sockets, or in wrappers that include authentication.
Oh, and FTP sucks. I can't think of a good reason to use it at all, ever. Use Samba if it's convenient, otherwise things like scp/sftp, rsync, or actual database replication.
Don't thank God, thank a doctor!
From DSA-1571-1 :
Affected keys include SSH keys, OpenVPN keys, DNSSEC keys, and key material for use in X.509 certificates and session keys used in SSL/TLS connections. Keys generated with GnuPG or GNUTLS are not affected, though.
God: An invisible friend for grown-ups.
I hope your scp setup has chroot cages set up, because otherwise, your clients can go poking around the rest of your SCP server and potentially do all sorts of damage. Keeping them from overfilling /tmp and /var/tmp on the server is difficult enough. Keeping them out of /etc/passwd to find account names is even more awkard: a secured SCP server is fairly awkward.
I've been seeing a few recommendations to instead use WebDAV over HTTPS. There are plenty of Java based clients, chroot cages are built in, and Windows has direct access to it over a browser for download, and using hte 'Network Connections' for upload. I also understand that is supports SSL keys quite well, for public/private key access.
You do not want to use FTP at all. FTP is a very insecure protocol. If the data is very confidential, then you need to secure it against
Remember no encryption is so good that it can't be cracked, given sufficient compute power and sufficient time, and that the profits from identity fraud are now sufficient to make it worth criminal gangs while to put significant resource into cracking encryption.
So to send this data, in my opinion, you need to split it into chunks which are in themselves of low value (i.e. first file, names and employee numbers; in the second file, social security numbers and employee numbers; in the third file, addresses and employee numbers; in the fourth file, ages and social security numbers; and so on); encrypt these chunks using different encryption keys, so that decrypting one will not provide the key to encrypting the next; and send them over a secure channel.
The UK Government has had a series of scandals recently where couriered media (CD-ROM disks) with valuable personal information has gone missing, so couriering this is not a good plan. Criminal gangs are apparently now willing to pay about US$50 per person for identity details like these, so in terms of value for unit mass, a CD with these details is worth much more than diamonds.
I'm old enough to remember when discussions on Slashdot were well informed.
Yes. The Russian mafia. They have much more than sufficient resource - not merely access to supercomputers, but also access to large botnets of other people's PCs. Cracking encryption is a task well suited to distributed computing.
Yes, these people can and routinely do crack military grade encryption, if the data is valuable enough. This data is valuable enough.
Highly unlikely.
What they (the attackers) are probably doing is either:
1) Man in the Middle (MITM) attack where the source/destination players (Alice & BoB) don't properly authenticate their encryption keys. Which lets them read all of the traffic by pretending to be the other end of the stream to each player.
2) Attacking the weak point of any encryption system - key management. Either by keylogging to obtain the passphrase, or other rootkit / cracking work to steal the private keys. Which then allows them to decrypt the messages. Getting key management correct is HARD (the devil is in the details).
3) Suborning either Alice or Bob (i.e. bribery or social engineering). Or simply via the lead lined rubber hose attack.
There's an awful lot of very very smart people out there who are looking at the current algorithms in use (AES, RSA, etc). If there were known weaknesses in the algorithms, we would have heard about them. Something that is encrypted with today's 256bit symmetric encryption algorithms is extremely secure for the foreseeable future (40+ years?). At least, as long as the encryption key is not leaked through some other fashion.
Wolde you bothe eate your cake, and have your cake?
"Remember no encryption is so good that it can't be cracked, given sufficient compute power and sufficient time, and that the profits from identity fraud are now sufficient to make it worth criminal gangs while to put significant resource into cracking encryption."
No practical encryption, that is. One-time pads are uncrackable. However, your statement is misleading -- for many types of encryption, "sufficient time" is longer than multiple human lifespans, even with access to a large amount of computing power. It's generally the non-encryption parts of a security system that fail.
Nor is chroot intended as a security tool, even though it's widely used as such. It's quite possible to break out of chroot jail.
Slay a dragon... over lunch!