State laws, company/client policy and common sense mandate the encryption of some forms of data. Whether its company secrets, PII (personally identifying information that isn’t already considered public), or ePHI (Electronic Protected Health Information) it is required that users encrypt this data when sent outside of the company, and it is on the IT Department to provide the right tools so this can occur. Bonus points for making it occur seamlessly and automatically.
This post looks at methods for protecting this data in transit via email.
1. S/MIME Encryption using Digital Certificates
S/MIME is built into most email clients. Once the certificate is installed, it is relatively easy to use if both sides have a digital certificate. When the otherside doesn’t have a digital certificate, unless you’re the 800 pound gorilla, good luck getting them to purchase a certificate and learning how to use it.
Most web mail clients do not support S/MIME. One exception is Outlook Web Access.
Cost and the difficulty getting the external user to use a digital certificate make this solution difficult.
2. PGP
PGP is another standards based email encryption solution. While there are free versions, they didn’t work well with Outlook the last time I used them.
This has the same problem as S/MIME in that the external person needs to be running PGP. Again good luck getting your external contact to change their ways.
3. A phone call
In a lot of cases we aren’t talking about moving a Excel spreadsheet of Social Security Numbers. We’re talking just one. A phone call (not leaving a voice mail) could be a lot more secure than email.
4. Encrypted Zip File
Encrypted ZIP files are easy to use, and use software already on many computers.
There are also many problems with Encrypted Zip files. The external mail server may be configured to block encrypted archives. It may not allow zip files at all.
You must pick a password that is good. Then communicate that password to the recipient over a separate channel (not email). If the user wants to use that file at a later date, they are probably going to go back to the original email. They wont have the decryption password anymore, and most likely neither will you. There isn’t a enterprise recovery option.
Encryption in zip files last time I checked was not really a standard. Winzip encryption at AES strength wouldn’t open in other zip clients. That may or may not be the case anymore.
5. Password protected Office document
You could password protect the Office document themselves. I haven’t checked if there are issues with password protected files between Microsoft Office versus Open Office. I do believe to get the best protection you need to use the current version of Office and then earlier versions of Office will have issues.
The same password lifecycle issues that occur with Encrypted Zip files also occur with Office documents.
6. Secure File Transfer Server
Products like Accellion can be used to transfer sensitive documents. These systems work most securely when you set up an account for the external person and communicate the password to them out-of-band. If the system automatically sends a link to the external user when a file is uploaded for them, anyone reading the email who gets there first can snag the file. At least it should be obvious that this has occurred. But the idea is moving files more securely.
7. Mandatory TLS to customer Site
TLS/SSL is what you are most likely using when accessing your bank site with a HTTPS://. It is possible to work with your customer/clients and set up mandatory routes that require TLS on all messages between the two domains.
The main drawback of this is it would need to be done for every customer domain that you deal with. It also encrypts all mail. TLS requires a bit more processing power. Shouldn’t be a problem for well spec’ed servers.
The mail is only encrypted in transport and is stored in the clear on the recipient and sender mailbox.
8. Opportunistic TLS
Opportunistic TLS attempts to use TLS on every mail connection. If it is not supported it sends the email in the clear.
While this means you only have to configure your mail server, you never know for sure that sensitive email is encrypted.
9. Hold for pickup
There are some mail systems that detect sensitive data in transport an then transparently act like the Server File Transfer Server. They notify the recipient that they have a message to pickup. The message is then picked up over SSL.
There are issues with each method of moving sensitive data via Email. But there are many options.
Posts tagged ‘eMail’
Protecting Sensitive Data in Email
Telecommuting Security
After the February snow storms in the DC area there was a plethora of articles advocating the expansion of telecommuting in the Federal Government. The contractors that support the government didn’t close doors. They continued to work because many of their employees already work remotely in structured and unstructured telecommuting. Telecommuting brings new security risks.
Joan Goodchild writes about Four Telecommuting Security Mistakes in ItWorld and CSOOnline. That s the starting point for this post.
1. Careless use of wifi and accessing unsecured networks
I don’t think people understand the security implications of “borrowing” someone else’s wifi or even using the free wifi hotspot at Panero/Wegmans/local shop.
Wireless is a shared medium. You don’t know who is listening in or even potentially hijacking your connection.
2. Letting family and friends use work issued devices.
We’ve seen laptops destroyed by letting the kids use them. (Although we could wonder if the user didn’t want to fess up that they were the one dumping the drink on the laptop repeatedly).
The kids violate security policy by installing P2P software, potentially sharing out all company data on the laptop. My favorite was the time the VP who signed the memo banning P2P was caught with P2P on the computer. Must be the kids.
If you allow your users to use USB thumb drives and the drive is shared with the kids, the data could easily be formatted or stolen.
3. Altering security settings to view blocked sites
Sadly this isn’t an issue for us because there is no filtering when you’re not at work.
People are apt to disable any security control that keeps them from their goal.
4. Leaving work issued devices in an insecure location
This is the standard problem. What is a secure location. Laptops are stolen at work. Laptops are stolen from the trunks of cars. You’ll recall the Veterans Affairs case where a laptop was stolen from home.
When you’re at the Starbucks, do you leave the computer on the table while refilling your drink, or hitting the restroom. People are far too trusting. Particularly when its not their property that will be stolen.
5. “Backing up” corporate data to a home computer or NAS
This should be against your companies policy. Proper enterprise backups don’t occur by copying files to what is probably an insecure location. Its just bad.
6. Emailing corporate data to your personal email account
Corporate and customer data have no place in personal email.
7. Secure disposal of papers
While at work its easy enough to put documents in the document destruction bin (which is pulped). At home if you’re lucky the data is shredded. Then again, dumpster diving at the CEOs house might turn up a lot of corporate data.
8. Incident Response
Was incident response built into your telecommuting program. Do users know who to call?
Messege Encoding and Blackberry
Last week a user reported trouble reading a message on his blackberry. He would get an error “This S\MIME message was formatted using an encoding that is not supported on handheld.” He could still read the message correctly in Outlook 2007 and in Outlook Web Access.
It turned out the commonality to the problem was him. On this Blackberry, he couldn’t read S/MIME signed messages where people were replying to him. Others couldn’t read his S/MIME signed messages on their Blackberry.
Since the error referred to the encoding of the message, I wanted to see what the encoding was. The headers in Outlook didn’t seem to include that so I opened the message in Thunderbird. In there, it was clear that the message body encoding was Cyrillic. Kind of weird that the Blackberry reads the message just fine if its not digitally signed but gets the error above when it is digitally signed.
RIM wasn’t much help. Their support gave the same answer found in a knowledge base article. Their choices are
- ,li>Do not sign and encrypt the message.
- In Microsoft Outlook, go to Tools > Options > Mail Format > International Options and select Auto select encoding for outgoing message.
- In Microsoft Outlook, go to Tools > Options > Mail Format > International Options > Preferred encoding for outgoing message and select Unicode UTF-8 encoding.
Not signing the email isn’t much of a solution. I worry that changing the encoding options in Outlook would effect the readability of email in other situations.
Microsoft has an article on configuring message encoding options in Outlook 2007. There we read that “Outlook uses automatic message encoding by default, scanning the entire text of the outgoing message to determine a minimal popular encoding for the message. Outlook selects an encoding that is capable of representing all of the characters and that is optimized so the majority of the receiving e-mail programs can interpret and render the content properly.” The KB has a table showing supported encodings and whether they are considered for autoselection by Outlook. The article does not state whether we could remove an encoding option however.
Through some trial and error, I found that the problem was in the signature (footer not the digital signature) of the person reporting the problem. He had used what looked like a pipe to separate portions of the signature (like Title and Company). It wasn’t a pipe, it was actually a character inserted through the Symbol key. If I replaced this symbol with a standard pipe character the problem went away completely.
While this was a quick fix for this user, its not very satisfying. Most likely this user saw someone else’s signature and copied it for his own use. I doubt this user was using ASCII codes or hitting the symbol button. If others did the same they would have the same issue. I prefer a better solution than put it in our KB for next time it gets reported.
Now you’re getting it
In December I set up a rule on our outbound email to let me know when people are sending Social Security Numbers in outbound email. Once I was satisfied with the accuracy of the rules, we set up some education for our physical security and HR Recruiters so they would understand why its a bad idea to send SSNs and what some alternative choices are . Once our big offenders had been notified I enabled a notification to the sender to let them know why emailing SSNs in plaintext is a bad idea. After about a month of that I reconfigured the rule so it blocked the email and notifies the sender.
One person who I believe is a finance manager got blocked while attempting to email papers for a personal mortgage refinance. A hilarious rant was sent to the helpdesk saying that if that people can read non-encrypted emails then non-encrypted email cant be used for business mail such as emailing a credit card number to enroll in a conference or when sending resumes that include SSNs.
Its so nice when the user gets it. Although I would have appreciated a ‘thanks for stopping me from shooting myself in the foot” tone instead of misplaced moral outrage.
I replied that she’s absolutely right. She should never be sending credit card numbers by email either. Some of the project/customer related data’s secrecy is dependent on the requirements of the customer and talking to the project lead about how to handle customer data would be appropriate. Unfortunately the company can’t allow emailing of SSNs.
SEPM Y2k.1
As anyone using Symantec Endpoint Manager (SEPM) to manage SEP11 clients should already know, SEPM has an issue where it thinks virus definition updates from 2010 are older than updates from 2009.
If you aren’t on top of this, you should be subscribed to Symantec emails here. I’d also apparently subscribed to something at the Symantec Forums at www.symantec.com/connect.
Symantec is just now starting to push out patches. Currently patches are available for 11.0.3. Keep an eye on this knowledge base article for updates.
So far this has caused three problems that I care about.
1. We use Forescout Counteract to monitor for virus definitions more than a week out of date. I came in one day and found all my computers in the “old definition” group. The defined action was run live update once. That wasn’t too big a problem.
2. Like most SEP admins, I have SEP configured to use SEPM for updates when on my corporate lan or VPNed in, but use Symantec’s liveupdate servers when on the Internet. It’s important for people to get updates even when away from the office, and that is a simpler solution than putting a live update server in the DMZ. The problem is the Y2K.1 issues was specific to SEPM. As a result Symantec foolishly used different virus definition numbers for their liveupdate servers and for updates through SEPM. So my internal clients are getting 12/31/2009 rev xyz definitions (where xyz is a incrementing number) and people who update directly from Symantec get normal updates dated today. If you are external to the company and you update from Symantec, your defs are dated 1/10/2010. If you go back to work, the defs offered from the server are 12/31/2009. You’ll never get updated while on the corporate network until Symantec fixes the original problem. To my understanding is you are now out of date. Kind of a big problem
3. Symantec by default notifies users of managed clients when the virus definitions are more than 30 days old. I take this to mean that unmanaged systems get no notification by default. In my environment managed systems are set to notify users if the virus definitions are more than 14 days out of date. Since we’re coming up fast on January 14th, I’ve disabled the notification. Of course any computer that isn’t on our network in the next couple of days wont get the new configuration.
Hopefully Symantec will get this issue resolved soon. Not sure why they couldn’t be ready to patch all SEPM builds at once. Why is MR3 so favored?
Adobe Flash and Air Updates
As you’ve no doubt read other places, Adobe has released updates for Flash and AIR. The security bulletin can be read here, the software can be downloaded from adobe.com.
I’ve found a bunch of our users have installed Adobe Air. Either they downloaded Adobe Reader 9 with AIR on their own or someone has screwed up the Ghost load. I’m leaning toward investigating how to deploy AIR updates rather than just emailing the users needing the AIR update.
It sure would be nice if the Enterprise distribution page included the file version. I either have to download and unpack the MSI to see if it is the new version or use another tool to check the modified file date on the webserver. Using http://headerviewer.com/ I see the last modified date is November 16th so it looks like I’ll be waiting a bit for the MSI version to be released.
Stop Emailing Social Security Numbers
Recently we implemented a product to do content control on email. One of the main uses I have is looking for Social Security Numbers (SSN) in outgoing email. I did not like what I found.
I expected to just find the occasional person emailing their SSN to a spouse for benefits enrollment. I’ve talked with people who said expect to find business processes that are mailing around SSNs like mad. I guess the result is somewhere in the middle.
It looks like part of having a government clearance is having your SSN emailed around in the clear. The Director of physical security says that when setting up a cleared visit at a Army base it is mandatory to email SSNs in clear text. I find this hard to believe.
People dont get what a social security number is. It a (generally) unique identifier but people use it as an authenticator.
The Social Security Administration Reports (http://www.ssa.gov/pubs/10064.html) that:
Identity theft is one of the fastest growing crimes in America. A dishonest person who has your Social Security number can use it to get other personal information about you. Identity thieves can use your number and your good credit to apply for more credit in your name. Then, they use the credit cards and do not pay the bills. You may not find out that someone is using your number until you are turned down for credit or you begin to get calls from unknown creditors demanding payment for items you never bought.
Someone illegally using your Social Security number and assuming your identity can cause a lot of problems
The Social Security Administration protects your Social Security number and keeps your records confidential. We do not give your number to anyone, except when authorized by law. You should be careful about sharing your number, even when you are asked for it. You should ask why your number is needed, how it will be used and what will happen if you refuse. The answers to these questions can help you decide if you want to give out your Social Security number.
Seems like the kind of thing you’d want kept secret. I know some people have given up. With the amount of people that you legitimately (or not) give your SSN to, is it really just a lost cause. I’d say given the trouble that identity theft can cause I’d take caution.
But that’s the problem, even if you knew enough not to email your SSN to your buddy so he can get you into the White House Christmas tour, your manager is emailing your SSN and everyone elses so that access to a cleared facility can be arranged. Your Tax preparer is emailing your 1040. Your dentist didn’t wipe the hard drive before selling old equipment on ebay.
Ultimately you can only control what you control. Make sure surrendering your SSN is necessary. At thie point I might even ask how it is stored/transported. Only provide the number over a secure medium.
iPhone (in)security in the enterprise
Just when you thought you’d successfully killed it off, its back. The email from management who is getting pressure from the c levels asking why the iPhone isn’t supported. It comes in on schedule every two month.
“iPhone version 3.1 has solved all the security problems, right?”
Um, no.
“There is now a Wolfram Alpha app for the iPhone. This would really help our business development”
Are you serious?
Who can blame them. Apple and their willing co-conspirators in the tech media have been repeating the mantra. “iPhone 3GS is secure for the enterprise.” Secure or not companies are adopting the iPhone, even to the point of allowing personal devices. Lets summarize what we know and what we dont know about the
Problem 1: Encryption
It is of critical importance to protect data privacy through encryption. iphoneinsecurity.com, a site dedicated to iphone forensics has posted video demonstrating the bypass of the iPhone 3GS encryption.
I suppose some would argue that the evil maid attack allows bypass of Full Disk Encryption on computers so I shouldn’t have my data there either. Of course using a smart card or bitlocker with TPM I could protect myself from this attack.
Problem 2: passcode bypass
The passcode on a iPhone is bypassable
Problem 3: Lack of Central Config Management
Enterprises are used to controlling phone configuration centrally a la through a Blackberry Enterprise Server. iPhones configuration is sort of voluntary. TrustDigital would say they solve that issue. I need to talk with them (again) because I think they can enforce a configuration at the time the iPhone connects to the server, but I dont think they have a permanent enforcement agent. Could be wrong.
Problem 4: patching
While patches can be pushed from the BES, iPhone users need to install each patch individually through iTunes
Problem 5: iTunes
Speaking of iTunes, that isn’t exactly a corporate type product. What if we dont want that on our computers. RIM has worked to make Blackberry work without installing any desktop software in a BES environment.
Problem 6: App Store
Whose account is used in iTunes? Do they use their personal account? In that case the end user really owns any applications purchased by the corporation on that account. When the employee terminates they would essentially walk out with the applications the company owns. If a corporate account is created then the opposite problem occurs.
Problem 7: Jailbroken phones
Jailbroken phones are susceptible to security problems. Besides the ikee worm, they allow unapproved applications to be run, bypassing Apple’s whitelisting security model. How can an enterprise prevent jail broken phones from being used?
Problem 8: Repeaters
Like a lot of company headquarters, ours is like a unintentional Faraday Cage. We’ve had to put up repeaters for Verizon and Nextel. Are we supposed to pony up and install AT&T repeaters?
While the iPhone remains exceedingly popular, it still has Apple’s consumer mindset at the core. (sorry bad pun) At least at our company I dont see it making headway until the encryption issue is solved. Then I’ll talk with TrustDigital again about their management solution.
update
The day I posted this I got emailed an announcement of Good Technology’s support for the iPhone. Good uses their own application and would keep the corporate email encrypted in that. However any other corporate data that made its way on to there wouldn’t be protected. In an era of cutbacks its hard to provide support for both Good and Blackberry.
Commenters have pointed out that the iPhone still does not support S/MIME or PGP. I had thought to check on that but it didn’t make the article. S/MIME support is mandatory for my company.
Cisco buys ScanSafe
I was surprised to read this evening that Cisco is buying ScanSafe.
I have been evaluating Web SaaS venders and looked at ScanSafe in September. To me ScanSafe has always been the market leader in web security as a service. I just had some issues that prevented us from going with them. According to a techtarget article, this purchase brings Cisco into the Web SaaS market and should play with their IronPort. I hope this purchase improves both companies.
As was stated when Barracuda bought Purewire, this validates the web SaaS market. It seem to repeat the recent acquisition phase of email SaaS venders. Is Zscaler now the odd man out, not yet having found a dance partner? I think not. There are still plenty of companies that think they need to buy into a SaaS presence.
