3

I'm hoping someone can point me in the right direction.

If I wanted to implement email encryption within an organisation what would be the best way? I've been searching the web tonight but all my searches just come up with PGP. However a web of trust approach doesn't appeal to me for an organisation.

Any suggestions? I would want the emails to be signed too, like in PGP.

Gilles 'SO- stop being evil'
  • 50,912
  • 13
  • 120
  • 179
  • 2
    [S/MIME](http://en.m.wikipedia.org/wiki/S/MIME) – mikeazo Nov 26 '14 at 02:45
  • 2
    Depends on how large the organization is. With a company of 50 people, setting up a keyserver for your PGP keys would be easy. Otherwise you could go the PKI route. Generate certificates for each user, sign them with your own CA. Email clients allow importing certificates into their store, and users can choose which ones they use for signing and encryption. – RoraΖ Nov 26 '14 at 15:15

3 Answers3

2

TL;DR - Use SMIME or PGP if you're paranoid of everything.

More information:

To answer your boiled-down question: How do you secure email? Practically speaking email is subject to attack by DNS spoofing, WIFI interception, and untrusted network administrators just to name a few.

To mitigate this you need to consider the different aspects that need security. It's likely most companies will fall short in security in at least one of the following areas, so anything you send could be in clear text and visible by someone other than your intended recipient.

Under each facet of security I listed relevant products grouped by how they are technically implemented. Ask yourself these questions based on the content you're sending over email:

Message Sender Verification

Does the recipient need proof that it was you who actually sent the message?

  • SenderID/SPF Records (weak verification)
  • Domain Keys / DKIM (strength depends on implementation)
  • DMARC (Strong validation of the display from user... hybrid of SenderID and DomainKeys)
  • PGP or s/MIME (may cause compliance issues if journaling or message auditing is required)
  • Portal-based products (Voltage, Proofpoint, Zixmail)
  • Microsoft RMS server + Outlook

Message Transport

Do I need to prevent unauthorized reading or modification of the email sender's MTA and my MTA?

  • Enforced TLS, with certificate validation. Non-validated certs are subject to MITM attacks.
  • Zix-based TLS is a private TLS network that doesn't require manual configuration
  • PGP or s/MIME (may cause compliance issues if journaling or message auditing is required)
  • Portal-based products (Voltage, Proofpoint, Zixmail)
  • Microsoft RMS server + Outlook

Reading the message

Must I ensure that only the intended recipient is able to read the message content?

  • PGP or s/MIME (may cause compliance issues if journaling or message auditing is required)
  • Portal-based products (Voltage, Proofpoint, Zixmail)
  • Microsoft RMS server

Must the client endpoint be secure? (applies if above 3 products aren't used)

  • The target network administrator is delivering email using a secure transport (Encrypted MAPI, POP3 over TLS, etc)
  • The target device is secure. This applies to workstations, and mobile devices.
  • Microsoft UAG adds features to OWA where the endpoint is audited and will delete left-over attachments in %temp% and restrict or deny access to features as policy dictates
  • An alternative to UAG is to block attachments from reaching the client (as Henri first mentioned)
makerofthings7
  • 50,090
  • 54
  • 250
  • 536
0

I don't know if you are looking to "roll your own" solution, or if your business is willing to invest in a commercial product.

If you are interested in a commercial product, Voltage Security has "Voltage SecureMail" http://www.voltage.com/products/securemail/ which would meet the needs you've described.

Dave Mulligan
  • 501
  • 4
  • 7
JesseM
  • 1,882
  • 9
  • 9
0

Firstly, glad you did not suggest designing your own; that way lies years of insecurity and support nightmares. PGP supports a PKI with X509 certificates[1], though few people use it that way. Another option is S/MIME, with certificates issued by a well-known CA[2]. Either way, you get central management of the hierarchy of trust and can skip the headaches associated with WOT.


1: See http://www.pgpi.org/doc/pgpintro/#p16
2: http://en.wikipedia.org/wiki/S/MIME

DTK
  • 1,190
  • 7
  • 8