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?"
PGP without pause
Redacted using FBI security techniques will guarantee absolutely nobody will be able to see it.
Make sure you send the password with the file.
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.
Deliver it by hand.... if you're lucky they'll give you one of those cool attache cases that handcuffs to your wrist.
Three Squirrels
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.
In particular, I'd suggest using PGP. It supports authentication of the data and is easy to use for individual files.
Ask the recipient to provide a public key over a known-secure channel (such as by courier).
Is there any reason you just can't email a TrueCrypt volume and tell her the password in person?
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.
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.
A game has objectives and is competitive, anything else is just play
Take some of those fur-lined handcuffs too. Do it on a Friday and get the weekend.
Engineering is the art of compromise.
Straight symmetric encryption with a key recited over the phone. No need to mess around with public keys and importing them and all that.
FTP over TLS is a decent and simple way.
"Destroy science and religion. Science would re-emerge exactly the same; but not religion." - Penn Jillette, paraphrased
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.
It's the only way to be near 100% sure it gets there unmolested.
The following has been my email sig for years. Did you know that, to date, only one person I know has made use of it?
Learn how to secure your email
(Mac OS X 10.3+) http://www.joar.com/certificates/
(Windows) http://www.marknoble.com/tutorial/smime/smime.aspx
...using TrueCrypt to secure the file then sending it via a secure FTP? It's exceedingly simple to use, and you secure it to your needs. All she has to do is mount the file and type in the password you give her. Tell her you will send the password via another means, and send it via registered mail making sure that there is absolutely no clue on the paper as to what the text means.
"So after all this, you make my case for me. To end this stalemate, you must die..."
If you're talking several gigs of data, put it on an encrypted drive and FedEx it. Send the password or key via encrypted email.
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.
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.
Make sure to install a stock, unpatched version of Debian Etch to ensure proper, secure entropy on your encrypted data.
Dearly,
The National Security Agency
Hand delivered by a trustworthy courier.
http://alternatives.rzero.com/
http://www.ownrecognizance.com/salliemae.html
"Your account updates are viewable in the attached PDF document. The file is password-protected and you need to enter your Social Security number to open it."
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.
If video games influenced behavior the Pac Man generation would be eating pills and running away from their problems.
thumb drive in your bum-bum
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?
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.
At least as secure as FTP/TLS and it's firewall-friendly. Takes either passwords or keys, or both.
There's good cross-platform support for the protocol, too, and lots of clients.
Hail Eris, full of mischief...
E pluribus sanguinem
You create a RSA certificate for you and for the consultant (destiny). Then you create an AES key (session key), and encrypt your data with AES, than you encrypt your AES key with the public RSA key of the destiny. So only the destiny will be able to decrypt your data, using the consultant private RSA key, that will decipher the encrypted AES key, that will be used to decipher the data.
Note that RSA is very, very slow, and this is why you should use AES over your data, and RSA will be only over the AES key. Also creating an AES key for each delivery will be more secure, since you won't use the same symmetric key over you data, and will reduce the possibility to attack your RSA key since the AES key will always change.
All of this are just basic usage of symmetric and asymmetric ciphers. Using this you also can send your data over e-mail, since security is not based in the protocol that you use, but is based in cryptography and math.
You can implement all of this easy with Java 1.6, that will work in many OS and already have support for RSA and AES to do all of the cryptography work. Java 1.5 doesn't have AES, that is the recommended symmetric cipher in this days.
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.
Do you mean you actually do not have a security policy for this? Do your employees know that?
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.
I was taught to respect my elders. The trouble is, it's getting harder and harder to find some.
continuous receipt chain beginning to end.
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.
- 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.
HTTPS w/ automatic encryption at rest: that's what I get in my "MOVEit DMZ" secure file transfer system. My occasional consultant uses the web browser of his/her choice, I can force them to use a cert to authenticate if I don't think a password will do and I don't have to mess with PGP or SMIME key management. (http://www.standardnetworks.com/moveit)
is post my requirements to a web site frequented by hackers. That way, they'd be able to get started tracking me down and be completely prepared to intercept and decode my sensitive data.
The right way to delivery a symmetric keys is using asymmetric key, like RSA. Where no hand delivery is needed and is very secure.
But you wouldn't have to distribute your private key. As long as you explain to the consultant that private keys are meant to be private, and you distribute the public key to the public, you should be pretty safe. The headache of public key encryption in this case is that it might take the consultant a bit of time to understand that before you can send the encrypted data to the target, he must obtain the target's public key. The target should be safe with public key... if someone sends them data signed with the wrong/malicious key, the target's private key simply won't decrypt it. So the source needs to be sure that they obtained the target's public key securely--either by having it signed by a trusted authority or distributed in a trusted way (physical delivery usually).
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.
scp ftw.
It always depend on how much you value security. The most secure way of transmitting big data that I've ever seen was to send a crypted CD by mail and send the password by phone or e-mail (can't remember which it was). It may be an overkill in your case...
Send a CSS encrypted iso of the data on a WEP encrypted wireless network that requires HDCP to display on her monitor with a signature generated by LM hashes from an unpatched, unfirewalled Windows 98 box.
Certified Mail is really the way to go on this if you can't email it. Pop it onto a CD, then put it into package. Seal the package with a way you know if its been tampered with or not. Then request a delivery receipt. You will have a record of transmittal, to whom, when, delivery, and confirmation.
Victory is gained, not in knowing your opponents next move, but in preempting them.
Even if you intercept the pigeon, you'll never be able to find the sender or receiver.
All you'll have is some unattributable data and a nice lunch.
OK I just know this sort of method will get mashed-up with PGP and be an FOSS project complete with a really cool pigeon icon inside of a year.
Blast. Should have called an IP lawyer.
"Win treats sysadmins better than users. Mac treats users better than sysadmins. Linux treats everyone like sysadmins."
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.
Looking for freelance Actionscript (Flash/Flex) or ColdFusion work and/or freelance developers. Email me, put Slashdot
Send the data by homing pigeon:
http://tools.ietf.org/html/rfc2549
He has the ability to hold data in his head. They even made a documentary about him called Johnny Mnemonic.
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.
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.
NeverVotedBush and Orange Crush are correct: getting it there is securely relatively easy, and the real problem is the HR Director considering sending this data offsite without having thought through the matter. Put your objection in writing, not to the sending of the data per se, but to the completely unknown security environment that DIr HR wants to entrust with your company data. Attach printouts of a few big employee data breaches (http://www.privacyrights.org/ar/ChronDataBreaches.htm#CP ) and then distribute to your management team.
In the hands of a bonded, insured, courier, into the hands of someone under a very draconian contract that spells out in a very big way what will happen to them if even a single record is leaked.
Seriously, this is not something you want to ever push across a network that has untrusted eyes anywhere, no matter what your encryption policy. Heck, you need to keep your own employees away from it even on the local network.
If the contractor is going to be putting it into new software that will run at your site, you need to bring the contractor into your facility to put the data in directly.
If the contractor is still developing the software, then the contractor doesn't get a single row of real data.
If the software runs somewhere else, you had better make sure that all appropriate measures are in place to safeguard the data, and you had better be REALLY sure that this offsite solution is the best option.
Once you let even a teeny tiny bit of this data out where someone can take it, you're in for a world of hurt.
One thing to keep in mind here is you are designing a system for a non technical person. PGP is a pain in the ass for anyone nontechnical to use. https is also going to create a every annyoing system for this HR person. You could properly set-up your e-mail server to require SSL with vaild 3rd party certs to send/receive mail and EVERYTHING to and from your mail server and clients will be SSL encrypted. Then make her an e-mail account on your system like cc-luser (if her name is Local User and she is a contractor.) Require only this e-mail be used to confer between her and the company. She is obviously used to using e-mail for this work, (and really it makes sense for this kind of information,) so this solution will minably impact her. I do agree you should try conver with HR and legal if possible to put it into her contract is libable for any damnaged resulting her failure to keep the information secure.
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.
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.)
Why not just establish a VPN with them and either secure FTP it or use IPSec? This honestly doesn't seem that hard, especially if you're sending a few gigs of data....
We are the all singing, all dancing crap of the world....
Don't forget that you may be working with a company that may be required to, or will at any rate, backup their email securely and store it for a long period of time. The same might be true of any data on the network. Then you are dealing with a situation where your data must not only be secured during this stage, but where you must trust the contractor to secure your data for years. What would happen if that information was compromised after the company folds up?
Any situation where your information is held by another party could involve risks to your company. These risks could endure for years, even after the other party has closed up and no longer able to insure the data themselves, potentially leaving all liability with your company with no recourse.
Example: Contractor closes shop in 4 years. Backup tapes are abandoned with no IT on staff to take ownership. Backup tapes are looted by hooligans. Hooligans use credit information of your employees to assume their identities and rack up bills in their names. Depending on the size of your company, 100's of employees decide to file suit against their employer over the reckless loss of their data. Your company has no one to put the burden on because the contractor is now out of business.
Sneakernet.
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.
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.
Frank Shoemaker would call it noise, though.
Comment removed based on user account deletion
NOT
0Courier
question. That's why I love /.
broad categories:
- spy jokes
- how to securely transfer files
- transfer is not the issue, safety at the other site is
- cover your ass
- safety at your site is probably an issue too, if plain email was the suggested method of transfer
Depending on the company, I would or would not, as a tech guy, broaden the question to points 3+ . Nobody likes a troublemaker/whistleblower. Mention at the coffee machine to the one giving the orders that data security issues during the transfer are by far not the only ones. If you have to, cover your ass in an email, not talking about your reservations but about doing the transfer as requested, and keep any emails on that subject.
Follow up a couple of weeks later with info on data security, and try to get the ball rolling from there, if you can get people motivated about the subject.
The Cloud - because you don't care if your apps and data are up in the air.
S/MIME is built into every modern e-mail client that I'm aware of. Microsoft Exchange Server has cert-generating features built in, or you can use OpenSSH. You can roll your own certs with no problem except for the mail program yammering about "unknown root CA". All the hoohah of "PKI" is only needed if you can't verify key fingerprints over the phone, or by some other out- of- band communication.
PGP/Gnupg works just fine, but it's a pain in the butt. Putting your data on a CD-R or USB memory stick (encrypted, please!) and hand- carrying it works, and will probably generate the least stomach acid.
BTW, if you can't trust your consultant to handle your data with security that's adequate (in *your* opinion, not theirs), get a new consultant (speaking as a consultant.)
Welcome to the Turing Tarpit, where everything is possible but nothing interesting is easy.
The right way to delivery a symmetric keys is using asymmetric key, like RSA. Where no hand delivery is needed and is very secure.
Uh, only if you have public key infrastructure (i.e. pre-trusted authorities). I can generate shared secrets all day long with Diffie Hellman, but it really only helps me if I know that the recipient is not a man in the middle.
"Nature doesn't care how smart you are. You can still be wrong." - Richard Feynman
Although the potential man-in-the-middle attack is a problem, this was used with great success in WW2 with normal messages - even the losses from German anti-pigeon falcons were minimized!
insecurity asks the wrong question irritation gives the wrong answer
Certified letter through the USPS? It's the government what could go wrong?
Say what?
They do the work, but why on their hardware, which you cannot trust. It must be on your production hardware, your secure data center, your password control, etc.
All data should stay inside your firewall. The system either has remote access or you can do a citrix thing, with a RSA secure id second key.
I like the idea of FTP over a site-to-site VPN the best. The VPN is created on the network side so you don't have to deal with PGP configuration on the client side, and you can restrict which hosts are allowed to access the server. By not exposing to outside your network you reduce the risk of brute force attacks. Note that FTP only works if this system uses a flat file (csv, xls, pdf, etc.) to store data/reporting.
The same idea applies to a database - send the traffic over a site-to-site VPN. Allow only the ports necessary to travel across the VPN (tcp 1433 on MSSQL, for instance), and set up restrictive accounts to allow them to query the database. Regardless, VPN is going to be your best (and safest) bet.
Unto the upright there arises light in the darkness...
Encrypt the data in such a way that losing a small bit renders the whole unrecoverable except by brute-force.
Then split the encrypted file into 2 parts. You now have 3 pieces of information that can be transmitted over different channels: Parts 1 and 2 of the file, and the password.
Using a one-time pad is even better but then you have 2x as much data to transmit.
Oh, hand-delivery and non-disclosure agreements as mentioned above help a lot also. Also, if you don't use an encryption method that doubles as a signing method, sign the data to make it tamper-evident.
Knowledge is how to play a game, intelligence is how to win, wisdom is knowing what game to play.
Individually uuencode each of your sensitive files, then zip-span them across multiple floppies. Place these floppies in a diplomatic pouch, and give it to Janine D .Hellmann (who is really Sydney Bristo in disguise). She then swaps the package for a replica. The real package is deposited on a cafe table in Barcelona (but it's really a set in Los Angeles. That's masking), where another agent picks it up. This agent proceeds directly to a safe house (incidently in one of Ben Affleck's mansions, but you're not supposed to know that). That's double-blind. YOU don't even know what your data is! Noe does your recipient!).
Ummm.. On second thought, just use GPG or Thawte Freemail, or one of the other myriad free mail signing and encryption services out there).
Spork.
P.S. Spork.
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.
Copy it to a truecrypted thumb drive then personally hand deliver the drive to the consultant's computer. No one but you has the password. You input the key on the new computer.
Semaphore
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.
"Here's what's happening. You're starting to drive like your Dad..." - Red Green
Double encrypt the data with two 2048 bit keys placed on 2 separate CDs carried by 2 different people on 2 different flights then have a 3rd person carry a CD with the encrypted data on a 3rd flight. For even better protection ensure that the 3 people do now know each other or the nature of the data they are carrying. Of course it may not be the most practical solution but if latency is not a factor it's going to take a very dedicated criminal/idiot to steal/leak this data.
I may agree with what you say, but I will defend to the death your right to face the consequences of saying it.
Someone mentioned above, burning it to cd. I've used this method in a simliar situation, where there were a whole number of issues I'm not going to go into here. In the end it was a bit of a "f$%& it" momment, just encrypt files, burn it to DVD. Get it couriered by a reputable service. It was simpler than clowning around with transfers.
It may take a while to get to the destination, but never under estimate the bandwidth of a small box full of DVDs in a truck.
If it's encrypted to all hell even if the DVD were to be lost or fall into the wrong hands it's just a useless piece of polycarbonate.
...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.
The problem with quotes on the internet, is that nobody bothers to check their veracity. -- Abraham Lincoln
There is an ancient technique that might be applicable here. You shave the skull of a slave and tattoo the data onto his scalp. Wait for the hair to grow back, then send the slave to the destination, where the skull will again be shaved. If further security is needed, you can encrypt the data before tattooing it on the scalp, and you can sedate the slave so that he doesn't know what you've done. This technique may not be legal in some jurisdictions.
First, there's lots of existing standards out here.
What does the US government use (or is supposed to use) to protect information like this for its own employees? Fips- 40-2 certified encryption products (which generally are FIPS 197 AES based, but FIPS 140-2 certification involves other tests). That's certainly one good standard to go by. (see note 1 at end though about keys)
Obviously many have mentioned PGP/GPG, A very solid option. Selected versions of PGP are also FIPS 140-2 certified (re-certifying every version can be expensive.), and this option has very good public key handling.
Many have pointed out various SSL based systems, https, ftp with SSL, etc. Also very solid, although it only handles the data while in-transit. Make sure it lands on a well trusted server. (ie: securing in transport doesn't help if the destination server gets hacked)
If you want to broaden out to other tools, in general, I'd stick with some basic rules:
1) must use at least 1024 bit public keys for key exchange, or at least 32 character passwords transfered by some other secure means (which is hard, so go public key). Good encryption won't help you if it's just passworded with an 8-character password of all lower-case letters (that's only 38-bits of key entropy, even if they're random).
2) must have at least a 128 bit key for the symmetric cypher.
3) Symmetric side encryption must be based on a reasonably secure cipher. AES, 3des, RC5, RC4 (careful of buggy implementations, ie: WEP), Twofish, Blowfish, square, CAST all have withstood a reasonable amount of attack without truly glaring weaknesses that radically reduce their real-world security. XORing with a 256-bit value has not.
4) Must use a cryptographic has function (MD5, SHA1, SHA2, etc) for message integrity. CRCs are only designed to detect errors in transmission, not malicious modifications in transit.
5) ideally should use public keys to establish the authenticity of the sender, but in this application that might not be necessary. You're more concerned about intercept than complete substitution of the file by a different sender.
-Matt
Setup a VPN between your two companies, your network guys should be able to setup a secure IPsec or PPTP tunnel.
Only allow traffic from a certain range or IP to a certain range or IP, over specific ports. Deny everything else.
This covers your ass from your company seeing theirs, and their company seeing yours, whilst still allowing access to the data, and only the data.
Rather than setup SCP over SSH or SFTP, which require learning of a new sort of client software, setup an authenticated HTTPS front end to the data - I'd assume everyone knows how to use a webpage, and save a file to the appropriate location - this encrypts the traffic (and password required to unlock it) whilst reducing end-user learning curve.
Many have already mentioned adequately secure means to deliver the data. The policies of the receiving company is probably out of your control, but at the very least all personally identifiable information (PII), such as what you are talking about, is mandated by the Privacy Act (and subsequent) to be controlled and protected almost to the same extreme as HIIPA. I would mark any PII I send outside the company with, "This data is controlled by the Privacy Act. Unauthorized use or release is prohibited," disclaimer statement at a bare minimum. Your legal division (if you have one) would likely have a hissy fit if they discovered PII was leaving the company without such a statement. If you don't have a legal department, then there's plenty of web resources on PII. Even if you can't come up with legalistic wording, these days no one has legitimate claim to the, "But, I didn't know," excuse when it comes to the federal PII protection requirements. In the military, all e-mails containing PII must be encrypted using smart cards. http://en.wikipedia.org/wiki/Personally_identifiable_information
Why move the data to the consultant, when you can move the consultant to the data?
Screw the IT angle. There's no financial benefit, and negative security benefit to be gained by setting up some one-off secure virtual network for a one-off event.
The only sensible method for delivering this is encrypted on a dvd-r in a case chained to a security professional's wrist, accompanied by n+ armed escorts, where n is a factor of the public value of the data.
Never underestimate the bandwidth of a professional courier.
kartune85 : Incapable of reason, observation or learning. A kind of dim, drab, flightless parrot.
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.
Why does the data ever need to leave your building / network in the first place? You can load up whatever software they need on a machine at your location, you can inspect it for security vulnerabilities, then you can move the data onto that machine, and they can manipulate it to their heart's content over the secure VPN connection. Data never leaves your place, you don't need to deal with surly postal workers, and your company never needs to worry about getting bad press for loosing millions of SSN's. Easy.
Why move the data to the consultant outside the firewall. Why not move the consultant inside. If you do not trust the consultant on a machine within your control why do you trust sending the information to them?
The SD crowd has clearly expresses it's love of PGP, and I have lot's of love for it too. But from a business perspective this is a much larger question. From a tech side there are other products such as Microsoft Right's Manager and Adobe's Policy Server.
http://www.adobe.com/products/livecycle/rightsmanagement/
I'm not endorsing either of these products (so save the flame wars), but identifying that this market is much larger than PGP. There also add a lot of other features, like restricting printing, restricting how long a file can be accessed, multi-factor authentication etc.
As for sending the data that you mentioned (SS#, DOB etc) this is a fine marriage of technology AND company policy, along with state, local, federal and national laws. For example the EU laws are very strict about sending this information and you need to be familiar with each nations requirements. Additionally, sending sensitive data across borders is a concern. As an example, a client could NOT outsource certain HR functions because of these laws. And when overseas certain HR develoment was done a thorough cleansing of the data needed to happen before it was either accessed or sent out of country (e.g. removing SS#'s Dob etc.)
In a nutshell you need your business to define what the security policies are, then use technology to the best you can to implement the policies. This is critical for SOX compliance and legal ramifications. Having the policy is almost, if not more important than the implementation often.
Cheers.
Your data is not your data, to paraphrase some trite poetaster or other. SSN's belong to the individuals who own them, not you, not your consultant. I agree with others here -- the heebiejeebie potential is mind melting. Can you imagine the class-action lawsuit your company faces if that data winds up in a Russian (Chinese, Bolivian, etc.) stolen identity database? First rule of security: It's not. The egg was open when the yolk went in, and the egg is open when the chick comes out. The fox is patient. Actually, that's too glib. "Security" is provided by processes having nothing to do with technology. The locked door shattered has merely proven breaking-and-entering, which triggers a whole new level of punitive retribution: I.e., the penalty for burglary is higher than the penalty for trespass. Any member in good standing knows the value of belonging. You want your consultant's fingerprints, her posted bond, a sample of her DNA and a set of mugshots, plus a background check.
``Tension, apprehension & dissension have begun!'' - Duffy Wyg&, in Alfred Bester's _The Demolished Man_
Set up a system on site for the consultant. Give them a VPN connection to that system so they can remote access it, and have the data loaded on site. The consultant doesn't have to make an unnecessary costly drive, and you don't have to let your data leave the premises.
it's not good sending it to them encrypted if they just decrypt it and store it themselfs in an insecure fashion.
If you mod me down, I will become more powerful than you can imagine....
The fact that the consultant's company doesn't already have a standard way of handling this should scare the crap out of you. This should have already been spelled out in the contract with the consultant.
Instead they've turned it back on you asking for your requirements. You will be held personally responsible when (not if) things go bad.
Really, you should only send them a dummy set for development. They shouldn't be dealing with real data until onsite testing later. There is no good reason to ship the a full, real dataset.
I would just tell the consultant that they have to do it on-site and on my companies hardware.
It really isn't clear what the circumstances are behind hiring the person, perhaps a compromise like I illustrated would work.
love is just extroverted narcissism
There seem to be two different and orthogonal security concerns raised in the discussion. The one question actually asked is how to securely transmit the data to the consultant. For that, the correct answer is either GPG or SSH/SCP. Either of those insure that the channel itself cannot be intercepted.
The second question is whether the data is secure once the consultant has it. A corollary of this is whether it is *really* necessary to give the consultant data access. Perhaps the answer is "no", but I'm not privy to the internal issues that make "yes" at least a plausible answer. Once the data is in the consultants hands--no matter *how* it was transmitted--it's only as secure as the consultant keeps it. Whether it is an encrypted data channel like SSH, a hand-delivered medium, or whatever, if the consultant can decrypt it she could potentially expose it.
Buy Text Processing in Python
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 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).
;) 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.
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.
Hope this gives a decent data point for your issue.
FedEx - never underestimate the capacity or security of a truck full of floppydisks.
http://www.sendsidenetworks.com/
They are like PayPal for documents. Secure, with tracking of who has read the documents. And the information doesn't leave their network.
The DoD allows classified information to be stored on AES-256 bit encrypted Kanguru flash drives. They come in at least 2 GB and 4 GB models. It would be best to take it over by hand on that if you really want secure.
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.
WinZip with AES 256 encryption using a very strong password delivered via phone is sufficient in some situations.
Horns are really just a broken halo.
Send real world data for a test? No Way! There are plenty of websites that will create any number of fake names, addresses, SSN, DOB, etc...and its free! You can even customize fields for your application.
It may take time but for moving huge amounts of bandwidth there's usually no better alternative, and you have much easier time keeping tabs on who's responsible for what.
Still waiting on Serviscope_minor to wake up to fucking reality and realize that Jessica Price isn't going to fuck him.
I would use Protectoria they provide a safe way to send sensitive information via e-mail without any initial setup
Slightly different scenario, in this case it's payroll information being sent to the company that deals with the payments.
The "consultants" suggested emailing it, when I said that wasn't going to happen they suggested putting it on an ftp site. (What the hell are we paying them for?)
As the people involved at both ends are not IT people and are all on Windows PGP isn't really an option, but S/Mime is. It also gives the advantage that you can say - go buy an email certificate from this website (pointing them at verisign/globalsign/another-t-t-p) and let them worry about the authentication issue.
S/Mime is integrated into all the common MUA software these days, certainly anything they'll be using on windows, and it's really quite easy to use.
The downside of it is that the security of the system boils down to key management & users. Once you've told them it's ok to email this information how do you guarantee that it's been sent encrypted?
Don't be a dick. I know that's you. Email me the data already.
... 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).
Copy the data to a hard disk, carry the hard disk between sites.
Data Mule.
It must have been something you assimilated. . . .
I've been using Dropbox 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.
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.
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.
One might also consider putting both systems out of the Internet and connecting them via a LL. Usage of crypto is still required, however 0day bugs (i.e. Debian's OpenSSL lib) will present less of a threat.
How to send confidential data like this? Archive to a large disk (DVD). Use more than one if necessary. Place DVD jewel case into briefcase. Handcuff briefcase to CIO. Cover handcuff so as not to arouse suspicion. Send CIO to destination. No hacking, no data loss, security problem, etc.
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.
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
Right in the bit bucket. Nobody needs MY info.
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.
I agree with the few posts I've read that've recommended PGP, but there's an easier alternative if you don't want to go through the hassle of setting up PGP keys for non-technical users: SFTP. It runs over SSH, so you're as secure as you would be when logged into a shell, and it doesn't matter which one of you has which side of the connection (client/server, I mean). There are probably some auxiliary benefits to SFTP, like controlling at least one place where the document is stored (as opposed to having it sit on some random company's email server, even in encrypted form), but the ease of use is probably the main reason to use it.
I'd probably be persuaded that the overall benefit of spreading the use of encrypted and digitally signed email is greater than the effort put into explaining to Suzy Secretary how to install Enigmail.
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
http://ask.slashdot.org/comments.pl?sid=560624&cid=23500510
http://ask.slashdot.org/comments.pl?sid=560624&cid=23500324
Encrypt the file with PGP and put it into a TrueCrypt container on a USB stick that requires a thumb-print for access and which is wrapped in a condom and 'hand' delivered by the 'mule' via the usual hidden methods. The access codes are encrypted into an image file delivered by uploading it to a porn site, the location of which is emailed to the intended recipient with a note saying something like, "Hey, check out this babe I was with last night."
I hope this comment is well received... I could have moderated instead!
Persecutors will be violated!
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.
In blocks of 1 megabyte
Generally public key encryption should be sufficient. Just send the data as an encrypted attachment using a private key (which you can tell him over the phone), and send the e-mail (with the attachment) using some kind of public key encryption like pgp.
OPTIONALLY: If you're extremely paranoid, you'll need a trusted 3rd party. So here's what ya' do: Send the data as an e-mail attachment using any kind of truly secure encryption. You can use any number of programs for this: trucrypt for windows, or gnupg for *nix for example. Encrypt the data with a good private key (don't use public key encryption), then get your trusted 3rd party on a conference call along with the consultant. You want a 3rd party who can verify the voice of whoever you're delivering the data to so that you can be sure that it's not some random dude claiming to be from company X and claiming to be person Y. Then you literally tell the person the password over the phone. That way you're both communicating in real-time using 2 different forms of transmission. If the potential interceptor of the data has both your phone lines and your network lines tapped, then you have bigger problems than this little transmission of data. If you wanna be truly paranoid, then you could insist that the receiver use his/her cell phone instead of a potentially IP-based company phone.
Your 3rd option is to physically deliver the data with body guards, a handcuffed briefcase, and CIA assassins present.
truecrypt + pendrive = encripted partition, yo could use a key file in adition (or only) to a password...
We do this every day at my employer.
First a 'Data Release Agreement' must be signed, in person. It blames the vendor if there are problems.
Next, we use SFTP access (sometimes SSL), bonded courier, or most commonly we tell the vendor to get their ass to our office.
If they want us to pay big money to migrate to their system, they damn well better show up.
How Would You Prefer to Send Sensitive Data?
Not.
If I find it's sensitive enough, it stays right here behind my steel door, and anyone who needs to use it can come and ask to use it, here.
"Good news, everyone!"
Stamped, self addressed envelope marked "SENSITIVE INFORMATION"
Couriers and encryption are all good ideas if you trust the person at the other end, but in your case the data you're dealing with is too sensitive. You could be responsible (yes, YOU!) for divulging all of your colleagues SSNs, bank account details, etc.
Any company that will not send an employee on-site to do the transfer - under supervision, or at least having accepted, under contract, responsibility for any data loss - shouldn't be doing the work.
Give your HR director a good slap for having agreed to this, and not respecting the security of all the employees.
Encrypt the data with a hashing algorithm (such as AES) with a key. Then encrypt the encrypted data with a different hashing algorithm (such as TwoFish) using a different key. Burn this encrypted data to a disc. Burn each of the keys to separate discs as well. Give the discs one each to three different people. Each person must have no knowledge of the other persons. Each person must take a distinctively different route and method of transportation to get to their destination. Each person is to hand deliver their said item at a slightly different time than his/her counterparts so their paths never cross. The data may then be reassembled at the destination by your consultant. Your consultant must physically destroy each disc such that the remnants of said destruction would not be easily identified as an optical disc.
One hassle-free way is to use password protected PDF.
Wtf? Are you serious?
If the consultant wishes to use Excel or similar office tools then they can work off the encrypted volume.
If they wish to import it into a database then they must show that the database software supports encrypted tables and prevents unauthorized dumps of data. They should provide details of which data leakage prevention tools they use (McAfee HDLP etc.)
Put in some fake data (different for each consultant) that would trace the leak source and, if possible, trigger some kind of alarm if used.
Transmitting sensitive data to the consultant isn't a problem. It's easy. PGP encryption using the consultant's public key confirmed via fingerprint check over the phone, then either e-mail the encrypted file or burn it to DVD and overnight it.
But what happens once it's in the consultant's hands? That's the rub. Once it's in their hands it will be decrypted and in the clear on their systems. It has to be. And you're trusting their security policies and procedures when you don't have any control over them or probably any idea what they are. And the consultant won't be the one suffering the fallout if the data's stolen from their network. Depending on how the contract's written they may not even be liable for the loss, and if they are liable you'll have to fight them in court and you're unlikely to recover a fraction of just your direct costs let alone the indirect, fuzzy costs like loss of reputation.
If it were me, I'd insist they do the work on my systems, connecting via IPSec VPN with proper key management protocols in place, with none of my data ever leaving my systems. And I'd still treat their systems as untrusted, have them VPN into an isolated network segment to do the work with solid firewalls between that segment and the rest of my network.
You have been using encrypted email all along, didn't you?
Activate checkbox "encrypt" and you are done.
then go to their office and type it out at their terminal.
Encrypt the file using your preferred strong encryption algorithm. Burn to CD. Double-envelope, the inner envelope bearing the name & address of recipient, also "COMMERCIAL IN CONFIDENCE" and security tape along all seams, with signatures on the tape. Name & address only on the outer envelope. Then deliver by trusted courier (or yourself) with the package signed for every time it changes hands. Final delivery should be made directly to a pre-arranged named individual within the receiving organisation.
The decryption key should be delivered in the same manner, but independently (a separate package, sent by a separate courier).
Something could still go wrong but at least this way you've shown due diligence.
Problem - once he decrypts the stuff, you're as secure as he is. If the consultant follows no guidelines and is sloppy - Truecrypt won't help you much.
I think the best solution is to set up a machine to which one can connect with VNC over SSH and see the data on the computer, without copying them off the server.
Naturally, the user account must be unable to establish outgoing connections anywhere, or initiate file transfers [from the VNC server to the client].
You'll need to use a good authentication mechanism, for example a smart card or a token (to avoid keyloggers). The key must be PIN protected; and the consultant must notify you ASAP if the key is lost or stolen, so that his account can be blocked.
Alternatively, you can use another authentication factor - biometry, so that even if someone steals the card and knows the PIN, they can't establish a connection.
There is a tool called Terminal Logon, developed by Dekart, it does all these things on a Windows client.
The saddest poem
In the past when we have required a high level of security for data transfers we setup a Business to Business VPN (B2BVPN). It requires that you have static public addresses but once setup it is transparent to the end users. Simply setup some space on a file server for them and then configure firewall policies to restrict access to just what they need (i.e. the file server). Also you can have as much or as little logging as you want. In my opinion it is the best way to deal with such a situation if you can get it setup.
No one said they want the data emailed to them; and even if they did, you don't have to interpret that literally.
The consultant is not an IT guru, and they probably don't know about secure transfer mechanisms. What she really meant was "I need to get access to the data somehow".
Quite often end users tend to express software requirements in a way that also tells you HOW to implement them. It is the job of the analyst to figure out what people need and then choose the best way to implement the feature. Obviously, it is not in the competence of the end user to decide how something will work.
She was just trying to be helpful, and suggested a mechanism she is familiar with; what's wrong with that?
The saddest poem
Just dump the data on a CD and send it by post. Don't bother with encryption - it'll just slow you down.
If you want to be really secure, put it in an Access database, and password protect it. Then write the password on a Post-It and put it in the same envelope as the CD.
This advice was brought to you by UK Revenue and Customs.
Except each shipment is accompanied by a squad of sardukar and instead of pgp/gpg we use the best cryptographic routines we can pry away from the spacing guild.
i've doing this using Concealar... 10MB master data? no problem... i just put it up on geocities as 20MB PNG, and then textmessage the password to the receiving party!!!111
;)
~
fvck b3ta!
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.
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
The Wise adapts himself to the world. The Fool adapts the world to himself. Therefore, all progress depends on the Fool.
Well, I think you've over-looked the obvious: snail mail. Hire a lot (2000 - 3000) of temps & they each write a letter containing all the details for an employee. You post these letters & as each one is sent, the temp who wrote the letter goes to the Consultant's offices & reads his or her letter & types it into the new system. That would work & everyone understands the method, too. Course, it might have a little delay, depending on the postman. Hope that helps -- not too technical, I'm hoping? Anyone else need knotty problems solved, let me know: I do have some time available for quite deep thought.
Most of the talk here is about forms of encryption, whether public-key cryptography will be compromised, etc. That's all well and good, but how many times have you heard of sensitive data being exposed because someone got it and broke the weak encryption? The average Joe whose hands the data will fall into probably won't know that the encrypted blob is anything sensitive or meaningful, and certainly won't know two bits about encryption. Usually data loss happens because an ignorant person copies the file to their laptop and leaves it somewhere, or forgets the CD marked "Account Information" in their car and gets it stolen.
The fact of the matter is that the biggest risks are who the consultant is, who else has access to their machines, and how much they care about protecting your information. Even if you don't use crypto over the network, I find it quite hard to fathom that your ISP is sniffing your data, and even if they were I doubt they could pick out the confidential information. That's a movie plot threat and not something that happens in the real world.
In analyzing this sort of risk, my opinion is that people are usually the biggest factor.
That's right, use a different key for each field and then gpg the end result with another key. Then rot 13 it for good measure.
I had to recently send a backup of data to a client for them to keep for audit purposes and in case we went bust.
I tarred the data up and encypted it with a random string run through aespipe. I then burnt the data to DVD and posted it to them. Once they confirmed they received the DVD I emailed them the key and told them to keep it safe.
Neither the DVD nor the key are any use on their own. The end user doesn't need any PKI setup at all. There is a readme on the DVD telling how to decrypt it, and they are tasked with keeping the key safe.
-Matt
No cameras.
Firstly, as a somewhat paranoid former sysadmin, I'd not want it to go outside of the firewall.
If management insist, then encrypt the compressed data file (PGP/GPG/etc), and either copy it to the person's laptop on site, or over a VPN. Given the issues here in the UK with sensitive information getting lost by the courier, I'd avoid that route, even with encryption.
Ideally, insistence on full disk encryption while this data is on her laptop (and tight restrictions on who has access on any server if it's put on one at her end - perhaps only permitting the encrypted copy to be left on there out of hours, or again disk encryption) - as other posters mentioned, people are the main issue here, with the potential for the laptop or media containing this data to be lost or stolen.
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.
By far the largest problem (95%+) with security isn't technology but the procedures involved with true security. Use any system that is safe and easy to handle. A good PGP setup (costs money), a good GPG setup (costs time) or - this is what I would do - file encrypter programms like KGPG. Those are the most hassle free to use - contrary to those bizar multi-standard email encryption setups that can easyly fail due to incompatabilities. There even are file compressors and archive programms out there that support encryption (check for the strength of that beforehand though).
Once you've done that and have esablished a secure pipeline to your adjacent on the other end see to it that his procedures are as secrue as yours. It might even be the best just taking an ecrypted stick or HDD over to him in person and help him migrate the data. That way you can ensure there is no leak on that end. If you're really serious about security, that's the way to do it.
We suffer more in our imagination than in reality. - Seneca
You want PGP. I've used this to transfer files of data worth millions* across the internet. The procedure is quite simple:
* Quite literally: the data being codes that granted temporal access to certain widely used commercial services, each code having a definite monetary value.
** Exactly how depends on what level of assurance is required and acceptable. Ideally you should exchange keys in person. If that is not possible, via a trusted intermediary. If that is not possible, via a distinct channel from normal channels of communication (e.g. post, mobile phone; landline phone as a last resort). You can exchange keys via email, and then verify the keys 'fingerprint' over a secure*** channel, if that secure channel lacks the bandwidth for key-exchange (e.g. voice phone ;) ).
*** Sufficiently secure for your needs that is. There are no absolutes in security.
I use Friend/Foe + mod-point modifiers as a karma/reputation system.
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.
Thanks for the heads up not to do business with your company and partner company who seeks the opinions of ./er's about sending peoples SSNs over the internet. The question you should be asking yourself is, how do banks and credit card companies handle such extremely sensitive personal data and use a consultant specializing in such matters. Otherwise your HR person has committed your company to exposing its behind to all sorts of legal entanglements.
My karma is not a Chameleon.
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.
no text
Have you ever considered simply implementing public key infrastructure using good old fashioned rsa certificates? Almost all email clients support smime and it does two things:
- Allows for encrypted messages (secure)
- Allows for automatic signing of messages (authentic)
PGP is another good choice, but it takes more work for the end user. Another nice feature of using PKI is that the same certificates can be used for web authentication as well!
-- $G
Never underestimate the bandwidth of a station wagon full of disks. The information on those disks is encrypted using PGP with a Really Big Key(tm) , of course.
Laws affecting technology will always be bad until enough techies become lawyers.
Technically, only the government should ever be asking for your Social Security Number. No one else (doctors offices, businesses, lenders, etc) should ever be asking for it, even though they do. Whenever I'm asked, I provide only the last 4 digits, and if that's insufficient for their purposes, then I refuse to do business with them.
Moderator hint: a comment is neither "Flamebait" nor "Troll" if it is true.
I think I can help here: step 3 is: 'apply copious amounts of lubricant'.
I would force the consultant to come on site and TEST, I would not let the data off the property.
1 small file a day? PGP through e-mail
1 large file? PGP via FTP/SFTP so this could be automated.
Continuous access to a DB? Probably interconected with some VPN solution.
Cracking a 1024bit key with a botnet of 2'000'000 computers, would take a tad less than 2*10^106 years.
By then, either the universe will have reach heat death, or we'll have developed more efficient cracking technologies (quantum computing) and conversely, more secure communication channels (quantum key distribution has seen experimental usage already - maybe one day, the technology would be able to do quantum *data* exchange).
"Sufficiently advanced satire is indistinguishable from reality." - [Tips: 1DrYakQDKCQ6y52z6QbnkxHXAocMZJE61o ]
Your question is kind of like asking how to secure the door into your paper house.
Yeah, jump through hoops to encrypt the data so that the consultant has to wait to decrypt it before they can either willfully or accidentally leak it on their end.
I have a lot of rants about security absurdity, and this is up there in the list.
There are lots of places in HR processing where some small subset of an individual's application data needs to be exposed in processing. In compartmentalizing data, you are wanting to expose as little as is possible.
If you are checking if some given person lived at a certain address at a certain time, the task gets broken up into parts. There is no need to expose personal information if the first task is to verify that the address did in fact exist at the time claimed. The second part, verifying the person lived there does need to expose the name of the person. However, if it is the same party that verifies both parts, the result of the first task can return a one-time encryption key which is used to encrypt the second request.
Part of compartmentalizing data, is to change data flow. Do not process down a single application, process across all applications. If you are verifying addresses, verify all addresses across all applications at the same time. Shuffle the data. It is harder for outside parties to associate one piece of data with any given person.
In internal processing, most of the time the people doing the processing do not need to know who the applicant is, in order to process some specific item. Use some random string for identification of data checked out for analysis, which is then used during data check in to put the analysis results in the correct place.
The most secure way to transmit data is via parcel. Spend a couple bucks, buy a thumbdrive big enough to hold the data. Then encrypt the data with truecrypt or PGP or GPG or whatever. Email the key to the recipient, and then overnite the encrypted database. Surely, your clients privacy is with the 30$ investment to your company?
Modding Trolls +1 inciteful since 1999
I would use SFTP.
Simple, easy to set up and windows clients are available.
à_à
If it's very sensitive data, I'd send it over on an inconspicious CD-ROM or DVD-ROM disk by reccommended express delivery.
If it's not quite that sensitive, encrypted VPN/SFTP do the trick.
systemd is not an init system. It's a GNU replacement.
A big tank, full of Nazis. This is absolutely secure for sending anything except Henry Jones.
What if Tetris was invented by Nazis?
Why should the data leave your control at all?
Your company is paying the consultant, why can't she come to you?
If that's impossible, look for a solution using a remote login and a technology like Citrix; she'll be able to work on one of your company's machines, but not copy/print/easily transfer data.
As other respondents have noted, the greatest risk is not in the transfer of data, but in everything that happens after the transfer, while the data is in the control of your consultant.
Not some fancy, expensive, uber-high-security bonded cleared and armored courier, either.
USPS Registered Mail.
If it's good enough for the government to send Secret-level classified information, it'll do just fine for a bunch of identities.
Facts do not cease to exist because they are ignored. - Aldous Huxley
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.
Tell the consultant that sensitive information like that cannot be sent outside of the organization. Get them to set things up inside your organization.
We have been asked to do a similar thing here - and said emphatically NO.
Make the consultant come on site and perform the operations on your equipment in your infrastructure.
If you send it PGP encrypted that only covers you during the transfer. What happens to the data after they unencrypt it? Do you trust them to securely delete it? I don't, not unless it is included in the contract.
Go have a look at distributed.net to see how effective thousands of computers are at breaking RC5 encryption with a 72 bit key. So far it's been going for 5.5 years or so and is at 0.495% of the keyspace http://stats.distributed.net/projects.php?project_id=8
This is only a 72 bit key by brute force. Try breaking AES 256, I dare you.
Just zip it all up and password protect it, come on!
-ducks-
Flappinbooger isn't my real name
I guess he's sending it to Alpha Centauri
No doubt SMIME. I used to be in charge of a large bank's IT/security and SMIME was it.
http://teasphere.wordpress.com - A little spot of tea
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:
I plan to write a blog post today or tomorrow at our blog, http://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.) 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.
Check out our infosecurity industry blog: http://securitymusings.com/
Use Truecrypt to create an encrypted file container, load your data and email or FTP at your leisure. You can phone the receiving party with the password and they can work with the data in the encrypted file container and neither of you have to worry about losing it, provided they unmount the file container when they're done and don't store the copied data anywhere else. I do it all the time. You can even transfer files back and forth between Windows and Linux with Truecrypt 5. I haven't tried the trifecta with OS X but I'm not seeing any reason that wouldn't work as well.
There really isn't any reason not to use encryption these days.
If you find Truecrypt useful, maybe making a little donation to support development might be nice.
That's our life, the big wheel of shit. - The Fat Man, Blue Tango Salvage
www.websafe.com (currently being renamed www.vitalesafe.com) provides encrypted sharing of folders over the Internet. Much easier to set up and maintain than a VPN (you could have a secure sharing configuration set up in less than 10 minutes). Requires no special client software (you can use browser, or WebDAV client, or free client-side sending software). Your data is protected end-to-end during the transfer and during the on-disk the storage. Every account has a unique encryption key. One of the design goals of our product is to meet just such a need as the one you outline. There are other features like online backup, Patient managed Health Record (PHR), and a Password Manager that can be used in addition to the secure sharing/collaboration. Free trial accounts are available (limited to 50Mb). Disclosure: I am the Director of Technology for WebSafe/vitalEsafe.
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--and they have insurance.
I've been doing this for 10 years, as a consultant. When I go into a company there's always some enthusiastic 25 year old who gets the suits excited. Recently I was asked to sign a 25 page agreement (this was for a contract worth $7K).
I didn't even read the agreement, I thanked them for their time, got up, and left the conference room.
They called me back and said that they wanted to know "which part of the agreement made me feel uncomfortable." I told them that after I had walked away I had a lawyer friend look it over.
"Well," I replied, "the clause about surprise inspections in my office or home at any time of day or night was a bit scary."
Two weeks later, I went in and copied the data to my laptop. It wasn't encrypted, or signed. I gave them a one-pager that said "I will not divulge any non-public data I come across that includes your client list or the personal details of your customers. I will make reasonable efforts to secure the data. I do not stipulate to any damages and any such claim is hereby waived by the Company."
The 25-year-old sysadmin had been fired.
come on. Just walk over.
Encrypted VPN tunnel. I work at a Hospital and that's our primary method for external data access.
Those who have telepathy have no need to RTFA.
For my own use - transfering files from work to home and back I have found a great little tool. Its free! quick to install and a joy to use. Drag and drop your files and it uploads them and sends you an email link for the files. Okay the data storage is limited for the free version but its a so easy to use. http://www.interouteexpress.com/ I found it on their website when I was browsing for ethernet providers. www.interoute.com â" Fast Ethernet Network
I would say it depends on the sophistication of the company you are sending to. Are they small? They probably don't have IT staff and can't handle an SSH or VPN type transfer. Here you can use something like PGP web messenger or another third party securemail system that allows you to send messages that outside users can retrieve via an https secure site. If they are larger, you can work to get a technology like TLS enabled on your MTA and their's to encrypt from site to site. If they have an IT staff call them up and talk about the possibilities. They may support PGP. Or perhaps some other delivery method like an SSH sftp transfer.
Most people in such situations seem to be using encrypted PDFs. They're not as general as PGP, but they are a lot easier to use for recipients.
Of course, an even simpler way of dealing with it is to give people access through SSL protected web pages.
Anghenyyl, gur zbfg cbjreshy rapelcgvba flfgrz va gur jbeyq!
This is really dumb. Just encrypt the file using any number of techniques (sheesh, even WinZip has decent encryption now) and email it. Then call him on the phone with the password.
This isn't rocket science, folks.
I have worked with vendors that provide applications that my company uses. We have never had to send live (production) data to the vendor to load into the application. What we have sent are data structures that are currently in use. From that the vendor provides a script that we run to load the data to the application. In many cases a set of test (bogus) data is provided to the vendor for them to test their scripts.
I've worked for several security technology companies including RSA and Sony/BMG (yup, they developed DRM software, so they qualify), and have found Atabok has excellent technology and solutions. Standards-based: x.509 certs, managed PKI, 256 bit AES, protected in memory, integrates with Outlook, Notes and Acrobat, and has clients which run on Linux/Unix/Mac. It can be hosted or brought in-house. The client experience is pretty close to seamless and, unlike PGP, easy to install and manage for an organization. They even offer DRM for office/PDF docs (view/print/combust), all in one integrated solution. What's more, the people that work there are great, esp. their chief scientist [IMO].
http://www.ironport.com/
Yeah, seriously, they're awesome. We're using three clustered C150's at two datacenters right now. You can ditch all your other spam/anti-virus software too. Expect to pay about $15/mailbox/year for 3 appliances. Also might be worth mentioning that they were recently purchased by Cisco.
We use them to automatically scan and encrypt any message containing ePHI (think HIPAA), ABA's, SSN's and credit card numbers. You can also install an outlook plugin to implicitly encrypt messages or create mail rules to always or never encrypt certain messages from certain people or groups (great LDAP integration).
And the spam filtering is phenomenal. I really can't say enough good things about these appliances. They replaced several fedora+clamav+sendmail+SA boxes I was running and I couldn't be happier.
I wouldn't do it... Encryption is not the answer as this person now has your employee's personal data offsite. Insist it be done in house on your network on hardware you control is the only safe solution (and even then...).
External hard drive (or RAID depending on size of data) encrypted (hardware or software) FedEx'd or couriered to the offsite location with the encryption key sent separately via a different carrier or mechanism. I use this scheme with my consulting clients and everyone is happy.
It's high latency, but it's great bandwidth and security.
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?
Tell HR to ask Legal.
If you do not already know the answer, you are the wrong person to turn to.
This answer is not meant to be disparaging.
two words: Bonded Courier
extended version: Ask what form they want the data in... burn to cd/dvd copy to tape/etc.
place in tamper-evident sealed bag, place in couriers hands with orders to release to nobody except the authorized person. ask for a signed reciept
I will not give in to the terrorists. I will not become fearful.
Use a data encryption program to encrypt the data first, then use rar and password protect it. Burn it to a cd and have the post office (or bonded courier) deliver it, get a signature, and have them return the receipt. Then you can give the person on the other end the passwords in person.
I'd say, here's your plain ticket, ship the server and software here, be prepared to stay awhile.
No data exchanges to anything belonging to the consultant.
No data removed from the premises to review for oddities overnight.
Laptops for use to browse the web, access web mail provided by the client, to remain on premises at all times.
Once the conversion is complete, send the consultant packing with nothing but his cellphone/pda.
But hey - I'm an evil data security monger...
Who is general failure, and why is he reading my hard drive?
Our small consulting company ran into this issue and developed ssldataexchange.com as a solution.
Simple idea really: our customers log in, create a subaccount for their business partner (or accountant), and upload files to our website.
Their business partners are notified about subaccount creation and emailed an initial password. This password must of course be changed at the first login. They will then be able to securely retrieve any files in folders they have permissions to read.
We offer flexible folder hierarchy, permissions, and notifications.
Overall it is meant as a substitute for something like a SFTP server, without the need for local server or client installation/configuration.
There was definitely a gap to be filled between easy to use but horribly insecure and secure but geekiness required.
It could always be worse,
At my office we deal in point-of-sale equipment and software. We often have to help customer's process batches of credit cards during their nightly close and sometimes the data has to be manually processed through the credit card processor. When the cards have to be manually processed, we send them a list of the transactions, the last 4 digits of the card number, as well as some other information.
I kid you not, they require us to accept full card number and customer information via fax, and will offer no other method. This is infuriating to us, as we go through e-fax and our faxes come in as plain email!
For those of you suggesting background checks, credit checks, attorney documents etc... you're all a bunch of idiots. I am a CISSP and a CISA. I deal with this kind of stuff on a daily basis. Here is a REAL recommendation. Please disregard all the other morons who think they know what they're talking about. Use SFTP. Use SSH-2 or above. It is a simple implementation, and there are many opensource options for you to choose from. It will provide you with the confidentiality you're looking for, as all data will be encrypted. You do not need to worry about background checks, credit checks, attorney documents etc. It's not like your company went and found some people in the alley behind your building and paid them to do some work and help your company with software. Chances are there is an agreement of some type between the consultants and your company. The consultants know what they are expected to do, they know their limitations, and they are aware of the consequences of deviation. Your company obviously trusts them enough to help them implement the software, and im betting this isn't their first rodeo. This is a simple task, with a simple solution. It's not rocket science. There is no need to complicate it anymore than it needs to be. If you follow my recommendations, you will be fine. If anything would happen, it's not your fault, it's senior managements fault. You didn't pick the consultants, you simply provided a safe means to allow your organization accomplish it's objective.
However, training our staff proved difficult, they kept getting hung up on the key exchange, even though they were reminded that it was only necessary to do this once per contact, and they would be assisted in this process. The other difficulty was partners and consultants were unwilling or unable to implement PGP (or something compatible) on their end.
Since PGP seemed too complex for the HR crowd, I tried implementing something that would be a bit simpler, and mirror their current process: encrypted zip files. Kludgy and ugly, but it fulfills HIPAA requirements (secure transport). Winzip is familiar and easy for them to use, and supports 256bit AES encryption. Before they send sensitive material, they call the recipient first to share the password, then send the data.
Never start vast projects with half-vast ideas.
On a USB drive. Encrypted with PGP. Via USPS registered mail. You provide her with the key via a separate medium, of course. And before you send her anything, make sure you have a contract that your lawyers have looked over where she both attests to being aware of your company's security and privacy policies and assumes all responsibility and liability for the security of the data once she receives the drive.
There's some good advice here already, and a lot of good questions that need to be answered before anyone could give a comprehensive answer. But having done a bit of this myself when I worked at "Large hardware vendor in The Valley" I've got a fairly simple combination to toss out.
1: Encrypt the data itself. PGP/GPG is your friend. If your consultant can't figure out how to use basic file encryption, find another vendor.
2: Confirm the keys. Face to face or on the phone, make sure you (and they) have the right keys on your ring.
3: Secure the transfer. In theory, properly encrypting the data itself should be enough. Even if the file's intercepted in transit, it should be unbreakable. That doesn't mean you shouldn't transfer it over a secure pipe. Pick your method here. SCP / SFTP are fine for point to point. So is burning the encrypted file to a CD/DVD and sending it via courier.
4: Accept the risk. Once the data's out of your hands, you no longer have control over it. You can't stop the contractor from signing for the package, decrypting the file, sticking it on a thumb drive in cleartext, and leaving the thumbdrive on the counter at Starbucks. Getting them to sign appropriate legal documentation will shift the liability, but won't actually stop the damage from the data getting out.
Your mileage may vary.
Cheers,
Bagheera
Never attribute to malice what can as easily be the result of incompetence...
As I understand, they are sending data to a contractor so he/she may populate a DB (or something) with data for an app migration. This is an unacceptable practice, no matter how you slice it, because ITS A CONTRACTOR.
I'm pretty sure the contractor can jump on a plane and perform the neccesary work on a known, secure platform without the requirement of sending data out. If not, I'm 100% there is another capable contractor willing to perform work in a safe, secure manner out there.
The net cost is easily justifiable, IMHO, compared to the cost of restoring business reputation from sloppy policies and process.
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.
IANAL but write like a drunk one.
Burn it to a disk and mail it. Registered mail, if you are REALLY paranoid. Cost is about $5.00. Security? Priceless.
One thing is to safeguard the integrity of the data (VPN) and another one is to safeguard access to a service (FTP).
It is ludicrous to suggest that both should be tied up.
IANAL but write like a drunk one.
How much cavalier can one get nowadays?
Everybody and his dog knows the flaws of ftp and it is almost certain that most people in your office will know which the ftp servers are.
Sorry, but your assumptions are rubbish.
sftp makes matters slightly less bad, but still has issues that need to be thought about and not dismissed as unlikely.
IANAL but write like a drunk one.
- Encrypt files
:)
- Rename files to Episode001...999.mpg
- Burn data to DVD(s)
- Label DVDs "Barney Reruns"
- Mail DVD(s)
No one will dare try to even look at it!
You force a guy to memorize all the data perfectly. put in his mouth an unidentified liquid, that such mixture cannot be purchased at the stores along the way. Have him run to the consultants if the liquid is gone from his mouth have him shot. Otherwise have him spit out the liquid and have it tested if it doesn't match (this can be given over the telephone after he gets there) have the messager shot. Otherwise the messager will realy the information to the consultants then given a brand new liquid to verify the information was recieved send him back to the company. Once again shoot the messager if the liquid is gone or missing. and repeat until all the information is shared. Once all the information is shared shoot the messager to insure that it will not be repeated.
If something is so important that you feel the need to post it on the internet... It probably isn't that important.
Just post it there. What could go wrong?
He who said 1,000,000 monkeys on 1,000,000 typewriters would eventually type the great novel, never saw an AOL chat room
Nowadays people can work remotely.
So make an account for your contractor and then control access to the data locally.
At the end there is also a degree of trust (enforceable by contracts) in which you evaluate if your business partners are capable and reputable, because no matter what you do, once a third party can read data they can copy it.
IANAL but write like a drunk one.
Wow - there are lots and lots of ridiculously complex solutions here. I'm assuming this is a one time data transfer. How about this:
1. Make a copy of the database
2. Encrypt it with PGP Disk or TrueCrypt.
3. Put it on a DVD, Flash or external hard drive.
4. Meet the consultant, hand the data to her and tell her the password. Alternatively, courier the DVD/flash drive to the consultant and give her the password over the phone.
I'm assuming you can identify person and there isn't going to be some movie plot threat involving imposters who assume the consultant's identity by getting her face surgically attached to theirs in an effort to steal your data.
Don't make it more difficult than it needs to be.
Two dedicated lines, two 56k modems, many small PKZip files w/ password protection, terminal software, Xmodem CRC, and a phone call to say "I'm dialing in RIGHT now, plug the server in." be sure that you answer manually, so war dialers can't get in!
By the time any VPN, PGP, or other encryption method is worked out a flash drive or CD or DVD with the data could be FedEx to the consultant.
Many years ago the pithy comment was "Never underestimate the bandwidth of a station wagon loaded with tapes."
Today it might be "Don't underestimate the bandwidth of a minivan loaded with DVDs."
JGT
JOAT(MON) Computer Psychiatrist
He made the best courier.
Make love, not reality television.
Your data will just go into databases that will be leaked or can be easily cracked one way or another.
I personally would be more concerned about what the consultant is doing to ensure data security on their end than how you transport it.
If it's within driving distance, encrypt it with PGP, burn it on a CD/DVD and send someone on a road trip. No complicated technical problems to deal with. Otherwise, send it through a courier service.
There is a lot of talk about secure ways to transfer this data off-site, but you should be trying to determine whether it is really necessary for them to load this data off-site. Once the data is off-site, encrypted or not, it is out of your control.....and that should give you pause.
It sounds like they want to load the data onto a system that they are building for you. I suspect that this system will eventually be installed at your office, not theirs. What they need to do is formalize the process for importing data from your existing system into their new system. There is no reason that they need to use live data for this purpose. At the very least, you should be able to create a file (or tables) with non-sensitive data fields filled with real data and sensitive fields filled with test data. This should allow them to perfect their import process. You should then load the real data only when they deliver the system to your location. Or as an alternative, you can then just update the records to fill in the sensitive data when the system arrives. Following this, you and the developer should then be able to perform a full series of tests with the real data before you deploy the system.
open source, free, and simple to use. Encrypting files and shredding(!) them after use.
If both organisations are using Exchange 2007, try Mutual TLS for domain security:
http://technet.microsoft.com/en-us/library/bb123543(EXCHG.80).aspx
This allows you to ensure the messages between organisations are always transmitted across encrypted channels. This is a good enough solution for most purposes, and if they are using Outlook 2007 it will tell them the message has went through secure channels.
If that's not enough (or you're not using Exchange 2007) and you have certificates for S/MIME, import the root certs into your organisation (if required) and exchange public keys. If the people emailing the secure data changes a lot, then you can publish the consultant's public keys to your GAL as a contact - see here: http://msexchangeteam.com/archive/2008/04/23/448761.aspx
Verify with policy if it should be sent at all.
Follow secure company policy guidelines every step of the way.
Secure the pipe, the client, the server and the data itself. And, breaking the file up into smaller chunks encrypted differently is a very good idea.
Though... the end of the day... you can do all the math you want... you don't need to try every key... you have to try every key until you find the right one. It doesn't matter how encrypted it is, it is possibly to stumble across the key by blind luck.
Where are you sending things that takes 25 years to post?
"It does not do to leave a live dragon out of your calculations, if you live near him." - Tolkien
don't EVER send something you value with bike-couriers:
the bad companies prefer to have too many couriers hired, ( it's piecework, so if there isn't enough work for you today, you just have to live on 1/2 minimum wage, or whatever it works out to, too bad... ), so while they "always have someone near you", they have few/no good couriers with 'em.
I've seen bikers destroy "fragile" marked packages as an effect of the way they are treated by their "employers" ( they aren't their employers: independent contractors, not employee agreements -- no rights, no standards, no minimum wage )
They also routinely leave your packages with any security guard who says they aren't allowed to bring other packages into the building with 'em.
Stuff goes missing? Well, the courier agreement means the courier company has no responsibility to you, too bad.
Do you trust either ego head security guards or people treated as that worthless by their source of income?
It's a quasi-large amount of data, and it's an infrequent thing. Duh, put the hard drive discretely into your pocket and plane/train/automobile/hoof it over. Bring a body-guard if you're actually woried about being mugged in your travels.
It's the standard answer, don't give it to anybody along the way, don't let someone else carry it for you. Look the contractor in the eye when you hand it to them directly.
What, have people forgotten that electronic data can still be carried?
The first question was "How would you prefer to send sensitive data?" along with "what would be on your wish list?". That allows one to ignore the question of "even if it should be sent" or "what about after it is sent". The second question was "What would be on your wishlist for the best way to send...?". That allows one to pick any method for sending. Therefore I would use (or want to use) quantum cryptography.
There a lot of problems where making the proper asumptions renders the solution almost authomatically.
I'll go first for the question: How can I securely send data to someone outside the firewall? I can go through a lengthy reasonement, but I'll just say: given the fact that you need to ask for such info, don't try. Just burn it on a CD or DVD or put it on a USB stick, an external hard disk or something like this and tell the consultant come to your office and give it to her with your HR Director testifying the transaction. It'll be cost-effective and it will be the most secure way you will find: since you got off the sending phase, there's not chance to mistake it. If it's terribly valuable data, it might happen that your consultor will be suplanted, but then any problem will be for the HR Director; remember he was there.
But then, do you really think the real problem is the transit? What if somebody hacks your consultor's PC? What if she's a villaine and just sells your data to the Russian mafia? That's the real problem. And once you have spotted the real problem, the answer rises by itself: Don't give your consultant the data! It's so easy it almost hurts.
Your company doesn't need a consultor to move your data from the old app to the new. Your company needs a consultor to write a program that will automatically migrate the data. But then, how will the consultor write the program without access to the real data? It can surely be corner-cases, exceptions... You need to provide her with "shaked" data: you just need to take the real data and randomly reorder the columns, then pass it to the programmer to test his program against it.
So, if your data is:
John Doe|123456|57 Some Street
Abe Avellin|789012|42 God's answer
Bob Bukowsky|345678|101 Nowhere's Lane
Your consultor will work against:
John Doe|789012|57 Some Street
Bob Bukowsky|345678|101 Nowhere's Lane
Abe Avellin|123456|42 God's answer
Any data nuisance is guaranteed to still be there, but the consultor will never put his hands on significative data (there's no Abe Avellin living in 42 God's answer with SSN 123456). Your consultor will never be able to reconstruct the deshuffled data but even then, if you still have any scrupples, you can shuffle the data even within any single register so "John Doe" becomes "oJDnh oe", etc.
I'm starting to consider my SSN public information. As of late it seems like any person that gives me money has to have a copy of it to file with the IRS. And who knows if they keep a copy of the form around, much what the IRS does with it.
It really is open an open secret.
Thumb drive in a condom, stuffed up the ass.
Better yet, make the consultants work on your site and watch them while they're there.
with something like this, I would think X.509 would be a better match. This allows you better options for verification than you get with PGP.
Usually I use GPG for similar things but I have it set up with the client before-hand and do an in-person exchange of keys. This is still not as good as you can get with X.509.
LedgerSMB: Open source Accounting/ERP
step 3 is: 'apply copious amounts of lubricant'.
Um...where exactly is this rail gun????
Soylent Green is peoplicious!
What the last three said.
Your HR Director should be kneecapped for even thinking of sending passwords offsite.
Unless... you're moving your infrastructure to another location (e.g. you'll be using a web-based HR system hosted by a third party), and the CONsultant is physically located inside that trust zone. In which case PGP it onto a DVD or tape, then courier it to the CONsultant. If you need to do this several times to include updates just regard the cost of the courier as the cost of reasonable confidence in privacy.
If the CONsultant needs to do a system test with realistic data, send them a batch of data created by extracting the real data then mangling and substituting random values for the real values.
If, as is moderately likely, your HR director forces you to do something flakey show them this topic, and if they still insist follow 'Secure in layers' by 'thomas (132075)': ignore 'shumacher (199043)' as he's talking about frequently sending to a large number of people: if the consultant doesn't understand your worries follow 'Jerf (17166)'.
If you are comfortable with the consultant having that data, and it is as simple as you state, then use the phone. Unless you think your phone lines are tapped, but the liklihood of that is far lower than the risk to which you're exposing yourself by transmiting the data electronically.
Skybuck's UDP File Transfer ;)
Oh yeah =D
Sorry, I haven't read all the comments here--some of the following are based on other comments, some are not (or not based on comments I read).
* First, I'd start with estimating the value of the data, or the cost of losing the data, or having a malicious 3rd party obtain the data.
* If that is a great deal, I'd consider not letting a contractor work on the data offsite, but instead insist on one of the following:
* The contractor work on site, under security procedures established specifically for this work
* If you need a contractor to develop the procedures to import the data to the new package, give her a sample (invalid) dataset and let her develop the procedures on that. She should provide a set of tests to confirm the procedures work properly, but you should have your own additional testing to confirm that the sample dataset hasn't missed any corner cases.
* Or, you may need the contractor to teach an "inside" employee how to import the data, with the contractor at "arms length" from the data. (Of course, this begs the question (in the UK sense) of how to make sure the inside employee (and your inside data security procedures) are adequate.
* I don't know how well bonding works, but if I did let the data offsite, I'd have the contractor post a gigantic bond, appropriate to the cost of data loss. (An issue here is how long the bond stays in effect--ideally it should be until the data loses it's value due to "attrition" (of whatever sort) over time.)
Another miscellaneous note--the idea that decryption takes a long time is based on averages (or whatever)--there is a chance that an attacker will guess the key on an early try. If I was an attacker, and the data was valuable enough, I might set an automated cracker to work on it on the off chance that I might get lucky.
hand delivered in a sealed lockbox- that's how we transfer confidential data at work
Take the entire fileset and encrypt the hell out of it. Then take the RAID3 approach, without redundancy. calculate the parity stripes out of the data. send one parity set on one disk via courier 1, the other parity set on another disk via courier 2. if either disk is intercepted, it is useless without it's counterpart. Even if both are intercepted somehow, they still have to figure out what all those ones and zero's mean, reconstruct the fileset, then deal with the encryption.
I would use a combination of digital certificates and encryption.