Forgot your password?
typodupeerror
Security

How Would You Prefer To Send Sensitive Data? 542

Posted by samzenpus
from the by-armored-truck dept.
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?"
This discussion has been archived. No new comments can be posted.

How Would You Prefer To Send Sensitive Data?

Comments Filter:
  • PGP (Score:5, Insightful)

    by Foldarn (1152051) on Wednesday May 21, 2008 @10:31PM (#23500152)
    PGP without pause
    • Re:PGP (Score:5, Informative)

      by Foldarn (1152051) on Wednesday May 21, 2008 @10:34PM (#23500182)
      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 (Score:5, Informative)

        by Foldarn (1152051) on Wednesday May 21, 2008 @10:35PM (#23500188)
        Correction:  ftp://user:password@10.10.10.10/yourfile.csv is the proper example link.
        • Re:PGP (Score:4, Informative)

          by The MAZZTer (911996) <megazzt@gma[ ]com ['il.' in gap]> on Wednesday May 21, 2008 @11:19PM (#23500532) Homepage
          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).
          • Re:PGP (Score:4, Funny)

            by Hojima (1228978) on Wednesday May 21, 2008 @11:29PM (#23500594)

            What would be on your wishlist for the best way to send sensitive data to someone outside your firewall?"
            1)Titanium alloy capsule with message 2)rail gun 3)???? 4)Message delivered (and/or profit)
          • Re:PGP (Score:5, Informative)

            by SanityInAnarchy (655584) <ninja@slaphack.com> on Thursday May 22, 2008 @12:28AM (#23500984) Journal
            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: (Score:3, Informative)

              by smallfries (601545)
              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.
          • Re:PGP (Score:5, Interesting)

            by Antique Geekmeister (740220) on Thursday May 22, 2008 @04:14AM (#23502102)
            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.
        • by emj (15659)
          You are missing the point, the worst thing that happens to the data is when it arrives to the consultant. These kinds of databases are something everyone sees value in, and makeing a copy is trivial. (Even though the consultants laptop isn't on the network, and not plugged into power)

          Make it very clear that this data can not be exposed. See some good posts:

          http://ask.slashdot.org/comments.pl?sid=560624&cid=23500514 [slashdot.org]
          http://ask.slashdot.org/comments.pl?sid=560624&cid=23500510 [slashdot.org]
          http://ask.slashdot.org/com [slashdot.org]
        • Re:PGP (Score:5, Informative)

          by Simon Brooke (45012) <stillyet@googlemail.com> on Thursday May 22, 2008 @04:41AM (#23502242) Homepage Journal

          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.

          • Re:PGP (Score:4, Informative)

            by blueg3 (192743) on Thursday May 22, 2008 @09:13AM (#23503992)
            "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:PGP (Score:5, Insightful)

        by Swampash (1131503) on Wednesday May 21, 2008 @11:01PM (#23500392)
        If this is for a work task (and in the parent article it obviously is) I would only ever send sensitive data via PGP-encrypted and -signed email, or more specifically via PGP-encrypted and -signed attachment to an email.

        Via encrypted signed email there's a paper trail. "The data you have is verifiably the data that I intended for you to receive, and the sensitive data haven't been mangled or modified (the hashes match), it is verifiably from me (that's my signature), and I have demonstrably met your request by sending you the information on this day at this time (email headers, server logs, whatever).

        If it's important and it's for work purposes, COVER ASS AT ALL TIMES.

         
        • Re:PGP (Score:5, Interesting)

          by Eskarel (565631) on Thursday May 22, 2008 @12:43AM (#23501064)
          Well e-mail isn't really a practical solution for a large volume data set, which presumably it is or there wouldn't be much point. So while PGP e-mail is quite a wonderful technique, it won't help much.

          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.

          • DVD/hand carried (Score:3, Insightful)

            by klubar (591384)
            Actually if you use USPS registered mail you'll get a traceable route of the data. If the data is super valuable, you can contract with a secured courier (think armored truck) to transport the CD. We occasionally do work for financial services firms, and since they already have a armored truck courier service for moving cash, it's easy for them to schedule a pick up with an armed guard.

            Even if the CD is stolen, it's still encrypted--and armored trucks (especially ones carrying data) are rarely held up--a
    • by NeverVotedBush (1041088) on Wednesday May 21, 2008 @10:53PM (#23500334)
      I agree completely with Orange Crush. You let that data out and it is now subject to this other entity's security policy.

      If you are going to let it off-site, is there a contractual agreement regarding how the data will be protected? Are their security policies audited by a third party? Worst case, does your company's insurance cover financial losses due to a third party mishandling your data?

      I'd provide them with dummy data in the proper format to simulate your company's data and do like Orange Crush suggests and put data and application together only on your own premises.

      But if you can't/won't do that, I'd say encrypt the hell out of it and burn it to CD, and send it by registered courier where someone has to sign for it to acknowledge chain of custody. Send the key by an alternate method.

      Do you know this company's security policies? Are there any kind of investigations/background checks performed on its employees? If it is a small shop, what kind of firewall protection do they use? Is some programmer's kid using his laptop to play games on the Internet and download "free" screen savers or ring tones?

      I assume that your data is in there too. How would you want it handled and what would you consider doing legally to your company if the data was in any way mishandled and your information to find its way into some identity thief's possession or posted on the web? What if your identity were to be stolen and your accounts raided or your credit ruined?

      I know this probably sounds fairly paranoid and I'm sure a lot of people might suggest easier and less secure approaches, but the reality is that this kind of data is a target and far too many people do not properly protect their business computer systems because they just don't realize how pervasive intrusions and spyware are.

      How would you want your data handled?
      • by NeverVotedBush (1041088) on Wednesday May 21, 2008 @11:10PM (#23500472)
        There are a lot of good posts in this topic. Especially the ones about the legal issues.

        These days a big issue is CYA when it comes to people's personal data. As others have noted, be sure to investigate any laws that might define how the data must be treated if it has to go off site. Be sure that your management signs off on the procedure and be sure you can document it.

        The days of just letting people download data are long gone. And don't use FTP if you do. Use the secure version (sftp) and encrypt the data before it transfers. That way it's an encrypted tunnel carrying encrypted data. But I wouldn't recommend this method. I'd get a signed chain of custody with media physically delivered and assurances that all copies of the data is completely and securely destroyed and the original media returned when the job is finished.

        Best way is not to let the data out in the first place.
      • by MyDixieWrecked (548719) on Wednesday May 21, 2008 @11:13PM (#23500490) Homepage Journal
        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.
      • I agree completely - getting the files TO the consultant securely is relatively easy... a GPGP key exchange followed by a phone call can pretty simply ensure who they are as well as anything. (I mean, as well as you know who the company is now - it's whoever answers their phone number.)

        But then they HAVE the data, and if you care about your data, that's a problem.

        In a perfect world, I would start by finding a new consultant - one who wouldn't even consider RECEIVING such data through email. I suppose in a PERFECT world, there wouldn't BE such consultants.

        But failing that you need to lay out every security policy you think is important to secure your data, including INSIDE a network... firewalls, care with files, background checks on IT staff, background checks on the consultants. You need this laid out in excruciating detail. And you need it in the contract with them.

        Ideally YOUR company needs to do the background checks on their staff... At a minimum you need to do a really sound credit check of them and have your attorney draw up a contract where they indemnify you for any loss due to a breach and any attorney fees to defend against and to recover from it. Etc.

        Basically the same kind of due diligence you'd have for someone you were letting come in and install new servers and new firewalls on your site with access to everything you've already got. Or if they refuse to get up to a reasonable standard, you can tell them they need to do their work on your site.

      • Red flag. (Score:5, Insightful)

        by PeanutButterBreath (1224570) on Wednesday May 21, 2008 @11:19PM (#23500538)
        If this consultant asked for this data to be sent via email in the first place, that is a big red flag to me. It suggests a pretty lax attitude towards sensitive data, possibly an indication of general cluelessness/laziness/hubris.

        Frankly, I would be a little suspicious of any person who wanted to take custody of this information at all if test data can be used instead. I would never take on that kind of liability if I didn't absolutely have to.

        In an environment where neither HR nor their contractor seem to have a clue, I would enumerate my concerns (in writing) and insist that they make the call (in writing). Too many weak links in this chain.
    • Re:PGP (Score:5, Insightful)

      by Metzli (184903) on Wednesday May 21, 2008 @11:15PM (#23500514)
      I would agree with PGP, once the proper legalities and assurances are in place. However, I'd worry about the non-technical issues before working on a technical solution.

      There are a number of issues to be resolved before worrying about how to get the data transferred. Has the consultant and/or their firm verified their security and controls to your firm's satisfaction with something like a SAS 70? Are there legal agreements in place concerning the proper controls of this data, the explanations or responsibilities in case of a disclosure, etc.? Has the idea been proposed to create bogus data for testing so that live data isn't used? Can the application be loaded on-site, so that a machine outside of your firm's control will not contain highly-sensitive employee data?

      I'd ask a lot of questions like these and get answers to my satisfaction before I sent out any data. I would greatly prefer to have to explain to my management why I'm "holding up the train" than have to explain to my coworkers why I was involved in the disclosure of their personal information and mine.
    • Re:PGP (Score:5, Insightful)

      by shri (17709) <shriramc@gma i l .com> on Wednesday May 21, 2008 @11:27PM (#23500588) Homepage
      I disagree. While PGP can transport the data securely, once decrypted, it will be rendered as insecure as the consultant's weakest point of security. If the data were truly sensitive, I'd send an anonymous set to the consultant, have them prepare a set of scripts / routines / procedures to import and then bring them onsite to complete the task.
    • Re:PGP (Score:5, Funny)

      by Anne_Nonymous (313852) on Thursday May 22, 2008 @12:03AM (#23500826) Homepage Journal
      Alternately, you could quantum encrypt the data, send the key by smoke signal, and nuke the entire site from orbit. It's the only way to be sure.
  • by Boogaroo (604901) on Wednesday May 21, 2008 @10:31PM (#23500154) Homepage
    Redacted using FBI security techniques will guarantee absolutely nobody will be able to see it.
    Make sure you send the password with the file.
  • Couple idea's (Score:4, Informative)

    by Drakin020 (980931) on Wednesday May 21, 2008 @10:31PM (#23500156)
    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: (Score:3, Interesting)

      by 77Punker (673758)
      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.
  • By Hand (Score:5, Funny)

    by rueger (210566) on Wednesday May 21, 2008 @10:32PM (#23500166) Homepage
    Deliver it by hand.... if you're lucky they'll give you one of those cool attache cases that handcuffs to your wrist.
    • Re:By Hand (Score:5, Funny)

      by Dirtside (91468) on Wednesday May 21, 2008 @10:39PM (#23500218) Journal
      No, if you're lucky, they'll include a key. If you're not, they'll include a hacksaw.
    • If she's cute.... (Score:5, Interesting)

      by EmbeddedJanitor (597831) on Wednesday May 21, 2008 @10:39PM (#23500220)
      Take some of those fur-lined handcuffs too. Do it on a Friday and get the weekend.
    • Re:By Hand (Score:5, Interesting)

      by Repton (60818) on Wednesday May 21, 2008 @10:46PM (#23500282) Homepage

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

    • Re: (Score:3, Interesting)

      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 se
  • by Orange Crush (934731) * on Wednesday May 21, 2008 @10:32PM (#23500170)
    Not at all if I could avoid it, that's for sure. Why can't the consultant import the data into the new package on-site? Even the most secure transmission method can't stop someone outside of your control exposing that data. I'd be talking to my HR people and begging them not to send this data out. Probably a good idea to talk to Legal too.
    • by Tex2000 (26062) on Wednesday May 21, 2008 @10:52PM (#23500324)

      The policy in my current company is that NO DATA is shared unless we have a "Non Disclosure Agreement" (NDA) Signed with the company/consultant that needs to work with our data. Have your legal department prepare such an agreement with items such as penalties for improper use of the information..

      This kind of agreement sometimes scare consultants or companies, and it's cause for some struggle, but in the end if they can't handle the responsibility over your data then you should find someone who can.
  • by rboatright (629657) on Wednesday May 21, 2008 @10:38PM (#23500206)
    unless the data set is so large that the answer is pgp on an external hard drive shipped by fedex. and send the password by a SEPERATE CHANNEL. I prefer to send the key by TELEPHONE -- spoken, but that's up to you.
  • Locally (Score:4, Insightful)

    by thedarknite (1031380) on Wednesday May 21, 2008 @10:38PM (#23500208) Homepage
    I'd get the consultant to come to the office. If the new software is going to be run onsite, there should be no reason why the data needs to leave. But if it does need to be taken offsite then having the consultant come in to collect it makes them responsible for keeping the data secure.
  • by Anonymous Coward on Wednesday May 21, 2008 @10:40PM (#23500236)
    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 (Score:5, Informative)

    by bluefoxlucid (723572) on Wednesday May 21, 2008 @10:41PM (#23500240) Journal
    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).
  • by RickRussellTX (755670) on Wednesday May 21, 2008 @10:46PM (#23500288)

    Simply use symmetric encryption (AES-256, for example) with a strong random key, then provide the key on a separate hand-delivered or voice-delivered medium.

    Public key doesn't really buy you anything in this case -- if somebody grabs their copy of the symmetric key, you're screwed. If somebody grabs their copy of the private key, you're screwed. Protecting the private key with an additional symmetric key doesn't make it more secure.

    But explaining to a clueless consultant how to keep a single key secure is a lot easier than trying to explain public key/private key operation.

  • Simple... (Score:4, Interesting)

    by Jane Q. Public (1010737) on Wednesday May 21, 2008 @10:46PM (#23500292)
    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.
  • Pinkerton (Score:5, Insightful)

    by tverbeek (457094) on Wednesday May 21, 2008 @10:50PM (#23500304) Homepage
    Hand delivered by a trustworthy courier.
    • Re: (Score:3, Insightful)

      by jamesh (87723)
      Or, if the consultant is somewhere nice, hand delivered in person. "Sorry boss, I don't trust anyone else to deliver this keyring sized memory stick to Hawaii."
  • OTP (Score:5, Funny)

    by Iamthecheese (1264298) on Wednesday May 21, 2008 @10:50PM (#23500310)
    Well, the first thing you need is physical security. I would reccommend Blackwater for their premium quality goons. You'll need at least two platoons and a morter squad. Then you'll want to hand-deliver a one time pad to their secure vault, with a completely off-network computer to do the decryption. You can solder off all the connections except a secure thumb drive for the OS and the DVD containing the OTP. You'll have to keep your own copy of the OTP in your own vault. And I highly recommend Windows ME on a Dell for the encryption routine.
  • Spy Style (Score:5, Funny)

    by bsDaemon (87307) on Wednesday May 21, 2008 @10:54PM (#23500342)
    Encrypt the drive and put it in a locked case, handcuffed to your wrist. Have a second person carry the key to the handcuffs and to the case and take a separate train. Just for good measures, send out decoys for both yourself and the man with they. Rendezvous at the consultant's headquarters.

    Don't forget to wear mirrored sunglasses.
  • by Geek_engineer (1293668) on Wednesday May 21, 2008 @10:56PM (#23500358)
    I would be much more worried about the security after you get the data there. How does the consultant protect his network (wireless???) and physical building? Does he keep the data encrypted so if a computer is stolen, it cannot be read? There are any number of good encryption methods to use in transmitting the data, then phone with the key.
    • Re: (Score:3, Insightful)

      by Swampash (1131503)
      I would be much more worried about the security after you get the data there.

      Speaking as if I was the poster of the original question, I don't care what happens to the security after I get the data there. It's not my problem.
  • by Alpha830RulZ (939527) on Wednesday May 21, 2008 @10:58PM (#23500370)
    If it were me, I wouldn't even be worried about FTP for a one time transfer. When was the last time , or the first time, you heard of someone sniffing sensitive data in mid transmission? The vast majority of compromise issues are due to compromise of files on a machine somewhere. You should be concerned about the work environment of the consultant, and procedures there, far more than how you get data to the consultant. Ad hoc work environments are usually far more lax in their controls than a production environment. HR departments are (in my experience) far less knowledgeable about how to protect data than IT types. This is where your risk lies.

    We use an SFTP server for transmission of financial data, and I don't lose a bit of sleep over it. You are at much higher risk for either your HR department or the consultant doing something stupid with the source or result files on their network. Your need is just to make sure that it doesn't happen on your watch.

    I would be more concerned about making sure that the HR folks and the consultant cleaned up their work files afterword.
  • Secure in layers (Score:5, Insightful)

    by sthomas (132075) on Wednesday May 21, 2008 @11:01PM (#23500390)
    If you are required to transfer the data outside of your organization, then there are two areas of concern - confidentiality of the data in transit, and confidentiality of the data once it arrives and is in the consultant's control.

    Data in transit:
    Encrypting the data prior to transfer is highly recommended, so that when it arrives it is in a secured package, and it also reduces risk should an email be misaddressed or forwarded to an unintended recipient. For this part PGP is an excellent tool. You can encrypt using exchanged keys, or you can encrypt using a strong passphrase and then communicate that passphrase out of band (phone call is preferable, separate email is workable but less preferable). For the method of transfer, securing the channel of communications is another added layer of security on top of encrypting the data ahead of time. If you are using an interactive transfer like (S)FTP, it will protect the authentication credentials from prying eyes. Although someone intercepting the PGP encrypted file now may not be able to decrypt it, tomorrow's technology may make the task trivial, so protecting it is recommended. TLS-encrypted email from organization to organization is also a good choice, but may be beyond the scope of your project. However, if this will be an ongoing need, or if your HR rep is also passing confidential content in email, it's definitely worth looking into.

    Data Protection after Transit:
    Once the person has received the file, your data will continue to be at risk. Each copy they make of the encrypted file is another file that could potentially be moved outside of a controlled environment. Once they decrypt the data, the risk to your organization climbs as they strip away another layer of protection. At this point the processes the consultant has in place are critical to protecting your data, and lack of processes or sloppy adherence puts your organization at risk. I often use users' Outlook Sent Items to show how easily copies of data files propagate. Anywhere they store the data, encrypted or not, may be released outside of their environment when they dispose of hard disks or tapes, or if they have them replaced because they are faulty. We empower users with tools, and those tools can increase risk in unexpected ways.

    Remember the most important security rule - always protect in layers. Remind everyone to treat all data like it's their own banking information or cash money. Require your partners/vendors/consultants to meet or exceed all of your controls. Allow as few copies of data (encrypted or non-) as absolutely required for operational and preservation purposes. Continually remind everyone of the potential risk of data loss. Make sure users understand that there is no single security solution - encryption provides one layer of protection, but the best security is constant vigilance and treating your data like it's cash money.

    I would recommend you have a serious discussion with your HR rep, starting out by saying "I just want to be sure you're aware of the risk here, and we are doing everything we can to protect our company and our employees." Then spell out the risks without exaggerating, and remind him/her that it's situations like this where bad decisions end up in the newspaper. The first decision is "do we have to move this data outside of our organization?" and it should only be done if it's absolutely required. If it is, then layering security and requiring that your vendor/contractor treat it with the right level of sensitivity are all that you can do.
  • by shumacher (199043) on Wednesday May 21, 2008 @11:02PM (#23500400) Homepage
    We wrestled with using GPG/PGP/X.509 and things like AES encrypted zip files for a while. No matter what, we couldn't trust:
    • 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.
  • my pick (Score:4, Interesting)

    by DragonTHC (208439) <Dragon@[ ]erslastwill.com ['gam' in gap]> on Wednesday May 21, 2008 @11:07PM (#23500438) Homepage Journal
    encrypted thumb drive.

    use truecrypt and create an encrypted file on a thumb drive. then if it gets lost, no one can retrieve it.
  • Registered Mail (Score:4, Insightful)

    by john.r.strohm (586791) on Wednesday May 21, 2008 @11:37PM (#23500638)
    I'd send it on CDs, by Registered Mail, the same way defense contractors and government agencies send classified stuff, for the same reasons.

    Yes, Registered Mail costs more. It is worth it. Registered Mail *EXISTS* for the sole purpose of shipping high-value items that MUST NOT GET LOST OR STOLEN. That is precisely what you have here.

    And for those of you in the peanut gallery: Yes, I have done Registered Mail. Several times. It is a pain in the ass. The Postal Service thinks it is a pain in the ass, and will try really hard to talk you out of it. I usually have to say "Registered Mail" two or three times before they figure out that I really do know what I want. I have had Postal Service clerks ask if I knew the difference between Registered and Certified. They were always very disappointed when they discovered that I *DID* know the difference, could explain it to them, and wasn't about to back down.

    If you are really paranoid, you send two packages, both by Registered Mail. One contains encrypted CDs. The other contains the decryption key. Or you split the data into two packages, that must be combined in a nonobvious way to reconstitute the data.

    But the KEY to the transfer is Registered Mail.
  • by Jerf (17166) on Wednesday May 21, 2008 @11:37PM (#23500646) Journal
    If the consultant really expected you to email the data, and expressed even a modicum of surprise that you wouldn't do it, they've already disqualified themselves from being able to securely handle your data.

    Do you really think that this is the only flaw in their handling of sensitive data? That, otherwise, they are security conscious and careful, except for this odd flaw where they don't understand how insecure email is?

    If you care, it's time to change consultants.

    If you don't care, just email it already.

    (I'm actually not quite as rigid as this may sound out-of-context. I don't agree that security is all-or-nothing, so please don't strawman me that way. My second paragraph is important; anyone who expects those things emailed to them is so far away from the necessary knowledge and skills that debating whether they are close enough or whether they will be able to take reasonable care is a waste of time, arguing about whether the receiver made a touchdown when they got tackled on the 10 yard line on the wrong side of the field.)
  • Emailed? (Score:3, Insightful)

    by e-scetic (1003976) on Wednesday May 21, 2008 @11:51PM (#23500744)
    If I was that consultant my first question would have been how to transfer that data securely - but maybe that's because I know what I'm doing. Therefore, I'd be totally allergic to giving that data to this consultant, regardless of any non-disclosure agreement.
  • What to do (Score:3, Insightful)

    by hejish (852589) on Wednesday May 21, 2008 @11:54PM (#23500766) Journal
    First, your company must have a policy. SSN's are sensitive data. Second, your company must have a contract with any folks not working for your company requiring that this data be protected in a manner compliant with your company policies. Third, the recommendation to have the consultant work on site or work with the data on site is appropriate. Requiring that the data NOT leave your site sounds very reasonable. If they are remote use 2-factor authentication to get into such sensitive data and administration of systems.
  • by beadfulthings (975812) on Thursday May 22, 2008 @12:19AM (#23500918) Journal
    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.
  • ...by email.

    This consultant wanted you to send it to them? I've been a consultant and developer for nearly 20 years. I would NEVER EVER ask for data like that to be sent to me. I wouldn't want to be anywhere near owning that kind of responsibility for someone else's critical data. You couldn't make me take it if you tried.

    Your biggest problem, as pointed out by others, isn't the in-transit data but rather what it does once the consultant gets it. If he's so unaware of modern security best practices as to ask you to send it to him, it's fairly a sure bet that his environment and practices are no where near good enough.
  • MY GOD!!! (Score:3, Insightful)

    by Jane Q. Public (1010737) on Thursday May 22, 2008 @12:34AM (#23501022)
    What overkill. People recommending multiple-step, even multiple-encryption, systems. And software that needs installing and configuring on both ends. And so on.

    As long as the file gets there safely, you don't care what they do with it on the other end, right? (That is the most common scenario.)

    So these people are trying to shoot ants with cannons. Massive overkill. REALLY all you need is scp, and unless you are running Windows, it is already built-in and needs little if any configuration. It's ready to fly.

    You would be hard pressed to get better security during transmission, and when it gets to the other end it is in its original form. No messing with keys or pads, no UN-encryption, in fact nothing at all for them to do. Send it via scp and there it is. All you need is for them to give you a username and password, which is a hell of a lot simpler than some of those other ideas.
  • by scrib (1277042) on Thursday May 22, 2008 @01:10AM (#23501200)
    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!
  • by elronxenu (117773) on Thursday May 22, 2008 @01:28AM (#23501276) Homepage

    You are about to send sensitive data to a third party who will load it into a new database and send you back the database. That's insane.

    You need to bring the destination (the database) in-house. Either load the data yourself, or get the consultant to come in-house to load the data. Under no circumstances should the sensitive data travel outside your network boundary. It's not a question of "how strong is my encryption" at all.

  • AES 256 (Score:4, Insightful)

    by Heembo (916647) on Thursday May 22, 2008 @01:34AM (#23501318) Journal
    WinZip with AES 256 encryption using a very strong password delivered via phone is sufficient in some situations.
  • Not by email... (Score:3, Insightful)

    by Secret Rabbit (914973) on Thursday May 22, 2008 @02:03AM (#23501466) Journal
    ... I what people seem not to get/missed.

    1) Strongly encrypt the data via your favourite method

    2) Setup an Sftp with a user name/strong password for the consultant*

    3) Send the user name/strong password to him/her via email (PGP/GPG)

    4) Keep the login log in a very safe place, along with any other email exchange, keys, etc that show the transfer has occurred and by whom.

    * If you want to have a even better "paper" trail, have them send you the IP of the host that they will be logging in from and limit access to just that host. Also have make sure that this IP is verifiable owned by the consultant firm. Keep the verification.

    If all of the above is done, you have made sure that the login has been done through the only *one* IP allowed (owned by the consultant firm), through a login that only one person has. So, any fuck-ups are there's and there's alone.

    But, if possible, I'd also require them to keep the data encrypted and only decrypted for use, preferable not to a HDD (ram disk). Not to mention any other mechanism that you can think of. Also make sure that the paper work requires any and all requirement to be applicable to any subcontractors as well as any of the subcontractors subcontractors, etc. Because, these consulting firms have a rather poor track record of keeping this data secure. And if they don't do it, and bad things happen, there is legal recourse on your part (as well as possibly the people who's data it is).
  • by johnlcallaway (165670) on Thursday May 22, 2008 @02:17AM (#23501534)
    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.

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

    So .. don't stop at just the transmission. Security has to be looked at from source to destination and archival.
    1. write wee scriptie that splits a file 3 ways byte 1 to file 1 byte 2 to file 2 byte 3 to file 3 byte 4 to file 1 ....
    2. write wee scriptie that merges them again.
    3. email scriptie to consultant.
    4. tar bzip2 the files.
    5. cut out 4 bytes from the middle of the tar ball.
    6. hex dump the 4 bytes and read them to him over the telephone.
    7. split the cut down tarball three ways.
    8. scp one to him, give him an https url for another, put the third on a usb pen and snail mail it.
      1. When he totally freaks out and starts screaming. Rename the file to GrowYourPenisNow.doc, spoof the From: header to be from hotmail.com, add a subject line V1agra and send.

        Nobody will ever bother to read it.

  • by JWSmythe (446288) * <jwsmythe@@@jwsmythe...com> on Thursday May 22, 2008 @03:00AM (#23501736) Homepage Journal
    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 [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.

  • by pla (258480) on Thursday May 22, 2008 @05:28AM (#23502460) Journal
    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.
  • by Yvanhoe (564877) on Thursday May 22, 2008 @05:32AM (#23502488) Journal
    It is of no use to set up a secure channel if the person you are sending to doesn't understand why you would like to secure these data
  • by ocbwilg (259828) on Thursday May 22, 2008 @06:36AM (#23502750)
    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?"

    Your consultant wanted you to email the personal data to them to begin with? Well, first on the wish list would be a new consultant, preferably one who takes security seriously enough to not ask that confidential personal data be sent via email. It's not like they don't know what kind of data they have there, and the lack of consideration for security in acquiring the data from you does not bode well for how it will be handled once they have it. I would probably require that they either come on site and work with the data via your machines on your network, or I would demand a partnership agreement with them that spells out hefty penalties if they fail to follow specified security practices, especially if that failure leads to data compromise.
  • Zixmail (Score:3, Interesting)

    by dlur (518696) <dlur.iw@net> on Thursday May 22, 2008 @08:44AM (#23503618) Homepage Journal
    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.
  • by flappinbooger (574405) on Thursday May 22, 2008 @08:55AM (#23503760) Homepage
    Just zip it all up and password protect it, come on!

    -ducks-
  • by DangerTenor (104151) <pmhesse2NO@SPAMgeminisecurity.com> on Thursday May 22, 2008 @09:09AM (#23503942) Homepage

    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.

Passwords are implemented as a result of insecurity.

Working...