Protecting Client/Sensitive Data

Trying to get an idea of what people are using at present for general data security, email, encryption, etc.

Currently we use a cloud provider for email, but this still has its limits in terms of what users are sending out to clients/partners.
One of my colleagues suppliers are using TLS to encrypt emails.   I see the benefit of this, however there are more issues here from users sending email to incorrect recipients my mistake, sending corporate emails/data on purpose, etc etc.

I see DLP is becoming more common.

I'd like to be able to filter out data and have a user authorise the content being sent, but also have ability to encrypt all emails that we are sending out..

Must make it easy and reliable from all sides..
Not sure where to start!

Who is Participating?
Adam BrownSr Solutions ArchitectCommented:
Most email traffic these days is encrypted through Opportunistic TLS, since most email servers have this enabled by default, but you can't rely on Opportunistic TLS as an encryption system since there is always a chance that the server you are sending to doesn't support TLS. Domain Authenticated TLS is another option that forces email to be encrypted under certain conditions. Both are available for most email servers and security appliances.

Another option is secure stubbing, which is likely what you get through your cloud solution, where a user sends an email and the recipient receives an email telling them to log in to a secure server to retrieve the message. It's a fairly reliable solution that will allow you to define conditions under which email is encrypted. You can set it up to encrypt all mail to a specific domain or have it scan the contents of a message for specific strings that could match a type of personally identifiable information (Driver's licenses, SSNs, CCNs, etc).

S/MIME is another option that utilizes a Public Key Infrastructure, where each user is provided with a certificate containing a public and private key that is used to encrypt emails. Encrypted emails can only be decrypted if the recipient has a copy of the sender's public key, which is emailed to the recipient before the encrypted message and installed by the recipient on their computer. This is a complex and fairly unwieldy solution, but it's supported by most email clients (Including outlook) and will protect email even if it is sent to the wrong person, unless that wrong person has a copy of the sender's public key.

Rights Management server in Windows server is also something you can use to ensure only specific recipients have the ability to open attachments, but it does not encrypt emails, only the attachments that are included with emails. Most DLP solutions will work like that.

And that's most of the email encryption systems available these days. There really isn't a perfect solution, but combinations of the above can help, since a layered approach is usually a good idea, but some of these solutions can't be combined. S/MIME won't work with stubbing, but will work with Opportunistic and Domain Auth TLS, and other such things.
CHI-LTDAuthor Commented:
okay, they have decided ALL emails should be encrypted.  How best to achieve this?

Im thinking of a cloud solution that they must use for attachments with client data on, and when the file has been read and or printed the document is deleted permanently and the recipient cannot read the email ever again.
Adam BrownSr Solutions ArchitectCommented:
Internal emails are encrypted by Exchange by default, so those are fine. Forcing encryption on all External emails can be very problematic, because you may end up communicating with a mail server that just doesn't support TLS, which is something you have no control over. You can mitigate this with email stubbing, where recipients are directed to log in to a secure portal to view emails, but that is unwieldy in the extreme. DLP is an option, but it's still a tricky thing to deal with. Rights Management Server may be able to help you with that, but you're going to run into headaches using the type of protection you're speaking of, since recipients could end up reading a file, accidentally closing it, and needing to have it resent to them.  Enforcing encryption on *all* emails requires a staggering amount of administrative overhead, and typically results in significantly decreased efficiency and productivity as people deal with the security measures. This is why most environments only enforce encryption for specific individuals, types of emails, or to specific recipient domains, all of which is much simpler to accomplish and require *much* less administrative effort.
CHI-LTDAuthor Commented:
ok thanks for your response.
Question has a verified solution.

Are you are experiencing a similar issue? Get a personalized answer when you ask a related question.

Have a better answer? Share it in a comment.

All Courses

From novice to tech pro — start learning today.