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?"
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.
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...
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?