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

Couple idea's

[Drakin020]

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.

Re:PGP

[Foldarn]

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 [10.10.10.10] that way it's almost dummy proof.

Re:PGP

[Foldarn]

Correction:  ftp://user:password@10.10.10.10/yourfile.csv is the proper example link.

Sending sensitive data isn't that hard.

[Anonymous Coward]

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.

E-Mail

[bluefoxlucid]

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).

Re:By Hand

[Hes Nikke]

and get the receipt notarized for crying out loud!

Re:PGP

[Foldarn]

Not being paranoid? He has to transfer the files containing sensitive information and that requires it not be intercepted by anybody but the intended recipient. In the financial sector, medical sector, any sector that deals with peoples' personal information or finances, security is the TOP priority. Assuring both your boss, you customers, and the federal government that you're in compliance is of the utmost importance. One slip and your company's credibility is gone. You know what they say, "Fool me once, shame on you. Fool me twice, shame on me."

Re:GPG? The Open Source Version of PGP

[MyDixieWrecked]

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.

Re:PGP

[The MAZZTer]

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).

Why not 7Zip

[Anonymous Coward]

Why not throw it in an encrypted 7zip self extractor file and deliver it to her by FTP or even email? It will give you 256 bit AES the only worry would be someone attempting to brute force it.

Re:encrypted filesystem on a USB drive

[sconeu]

Seriously, yes.

Back when I worked for a defense contractor, FedEx was legal for shipping classified hard drives.

Old Grouch Here (Or maybe Old Farte)

[beadfulthings]

I wouldn't send it to her at all. I'd take it to the consultants and stick around while it's being used, or have them come to my facility to use it under my control and conforming to my policies and procedures. You can use the most ultra-secure encryption you want, and you've got no clue as to what's going to happen as soon as the data gets to the other side. The first rule of security has always been "install a good lock on the door to the computer room." The other platitude that applies here is "good fences make good neighbors." Or in other words, if the consultants don't like your security, you probably need new consultants. The idea of taking the data away from the premises, loading it into a brand-new package, and then bringing the whole thing back inside just gives me the heebie-jeebies. Your HR people need you to tell them this. That's why they're doing HR and you're doing IT.

Re:PGP

[cayenne8]

"Yes, it's already authenticated, but most email systems will not route email over that VPN. It will route it to the publicly accessible IP."

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.

Re:PGP

[SanityInAnarchy]

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.

Re:PGP

[cheater512]

Ditch the passwords and use SSH keys.
Then only the person who is allowed to see it can.

too lazy to do key management ... used voltage

[zir0z]

I had a similar exercise that I went though a couple of years ago with a former employer (10k+ primarily non-technical user base, financial services company, approx 1mm outbound messages per day including automated processes, approx 30%+ contained sensitive info like acct numbers and SSNs that needed to be encrypted, and recipients were a mix of corp users and users that used free email accts as their primary address).

Email was pretty much the file transfer mechanism of choice for the business (for better or worse).

Major issues from my team (Info Sec):
1) how do we stay out of the key management business (anybody that has been to the key ring, PKI, certificate, etc. management barbecue knows what I am talking about here)
2) that we get all the mail off of our systems at the time of delivery (basically, in the wild world of e-discovery, we did not want to have to get into managing other company's 'sensitive emails')
3) no software required on the recipient's machine

I have used, tinkered with, been burned by, loved, and hated pretty much all the top players in this space... but based on our requirements and my personal motivation to just solve my email encryption problem and go back to my other work without needing to tie up resources to support users that were now using the implementation... I went with Voltage (http://www.voltage.com). It took two change control windows to get it into prod (one to test, and one to go live). For the sensitive email traffic that was not handled by gratuitous SSL/TLS (roughly 100k+ messages per day) we used Voltage at the gateway with users entering a key word in the subject line to encrypt. It took a little bit of training and some internal showing of dirty laundry, but users eventually caught on... and within about 3mos of implementation we were dealing with high 100s to low 1000s of user violations. We could have dropped the number to 0 by rigging our DLP product into the mix and forcing all remaining sensitive data flagged by our DLP solution to go through Voltage, but the business was happy with the drop in violations and did not want to do that.

In short, we dropped our plain text email violations from about 300k+ per day to about 1k per day, nobody had to do the key management dance, and no residual customer email was left in our environment. As a side note, Voltage also has a SAAS product that is completely managed by them that we referred our power recipients and business partners off to... once again, no work there for me or my team. ;) At the time that I left, we had the solution in play for 3 years and only had about a half a dozen support tickets opened on the solution - and basically, they were from users that did not read the web page they were looking at.

Hope this gives a decent data point for your issue.

Re:PGP

[andy.ruddock]

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.

Dropbox is simple enough

[SethKinast]

I've been using Dropbox [getdropbox.com] to move stuff between laboratories that needs to be updated by more than one party. It's all encrypted and stored server-side, and it's pretty much transparent to the end user since you just drop files into what looks like a normal folder. That eschews all the complexity of PGP or making FTP users, and is secure as long as physical access to the machines is locked down.

In lieu of new consultant, require data standards!

[Anonymous Coward]

I do consulting with HIPAA requirements. Makes me a little nervous that only after you bring it up, THEN they ask about data security requirements, especially when they SHOULD know about the sensitivity of this data these days.

However, assuming that you can't do anything about it, here are the methods I have used, depending on the capabilities of the client:
1) standard FTP of PGP encrypted files
2) sftp/https using digital certificate authentication
3) e-mail of PGP enrypted attachments
4) enrypted private VPN tunnel (IPSec)

Where do I store this data? On a truecrypted volume, manually mounted if the system reboots (password NOT stored anywhere on the system). If my office gets broken into, they only have a useless disk of gibberish.

Re:PGP

[Antique Geekmeister]

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.

Re:PGP

[Simon Brooke]

Correction: ftp://10.10.10.10/yourfile.csv [10.10.10.10] is the proper example link.

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

• An attacker pretending to be the designated recipient
• An attacker capturing the stream in flight
  • Where that attacker is within your network
  • Where that attacker is within the recipient's network
  • Where that attacker is between your network and the recipients

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.

Do you want theory or reality?

[pla]

First, to every other respondant so far - Know your audience. Non-geeks do not use PGP (hell, only a small fraction of geeks even use it), and most people only use SSL when/if their browser makes it 100% transparent. Don't even mention those, you'll just confuse the intended recipient and get nothing accomplished.

For the "real" answer - Using WinZip, pick 256-bit AES encryption and zip your file. Then send it via regular email, and call the recipient with the password (and although you don't need to pick an easy password, prepare to have to repeat it a few dozen times if you choose anything even remotely secure).

That satisfies any privacy/data security laws applicable to the situation, including HIPAA (presuming the recipient actually has the right to access the requested data) if this happens to involve sending medical records. No, not a glamorous solution, but it works.

Re:PGP

[smallfries]

You shouldn't assume that VPN access is per-machine. Our network for example authenticates each user on the VPN *and* ensures that the machine is registered. I don't think that is uncommon.

hold it

[nguy]

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.

You can use chroot as an additional security blanket, to protect against possible bugs in scp. But if you don't use chroot, that doesn't mean "your clients can go poking around the rest of your SCP server". Furthermore, there are many alternatives to chroot, including vserver and AppArmor.

chroot cages are built in

There are plenty of webdav implementations that do not come with chroot.

I'm sorry, but a little knowledge is dangerous when it comes to security, and your blind faith in chroot is dangerous. Chroot is neither necessary nor sufficient for ensuring security.

Re:PGP

[WuphonsReach]

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.

Re:PGP

[DaveHowe]

PGP is a good choice for either email or file encryption (done right, s/mime isn't terrible for the former either) provided the recipient can support it.

if this is just a oneshot deal, its probably easier to provide them with a password protected archive and give them the password verbally (over the phone) - good choices here are anything that uses 256 bit aes or the equivalent, so rar, winzip and 7z (which is opensource/free) are good choices.

Re:PGP

[|DeN|niS]

Ugh, yes, sorry.

What I meant is that every extra bit doubles the effort, i.e. going from 128 to 256 bits is not doubling the effort, it is squaring it.

You need a security policy.

[DangerTenor]

I can't stress this enough. You need a company information security policy.

Your information security policy should at a minimum cover the following items:

• Definition of critical business information (CBI)
• Definition of personally identifiable information (PII)
• Who can and cannot have access to CBI and PII
• How CBI and PII must be protected when stored
• How CBI and PII must be protected when transmitted
• How systems which store, transmit, or process CBI and PII must be protected to ensure the safety of the information (e.g. anti-virus, disk encryption, firewalls, etc.)

I plan to write a blog post today or tomorrow at our blog, http://securitymusings.com [securitymusings.com] which will go into a little more detail on this.

Now for a direct answer to your question: strongly encrypt the data using a 128-bit (or longer) standard encryption algorithm such as 3DES, AES, or Blowfish. If you are using password-based encryption, use a long and random password, such as those generated by any good password generation application. (GRC has a web-based one. [grc.com]) Use at least 20 random characters to create a sufficiently entropic password. Communicate the password out-of-band, such as via telephone, fax, or mail/fedex. There are lots of available tools to do proper encryption, such as PGP/GPG, WinZip, etc. Use one, don't write your own.

Re:PGP

[blueg3]

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

Re:hold it

[nahdude812]

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.

Not SFTP

[jotaeleemeese]

It is vulnerable to man in the middle attacks, unless you buy a commercial solution with host authentication.

I have no expertise with setting up VPNs, but a similar situation may arise.