0

We are interested in rising the security level of the corporate emails for a few reasons: 1) Protect internal information from leaks. 2) Mails to customers would be Signed. 3) A way to mark that a mail came from the outside (to prevent social engineering attacks fishing for things, or trying to issue orders instead of a manager etc).

As a solution, we are thinking of this schema (I know GPG pretty well, so I will use these terms to describe the solution):

1) All internal emails (from/to corporate domain(s) would be sent encrypted, using the Employee's GPG secret key, which would be signed by a master key (CA key for the whole corporation).

2) Emails sent outside to customers, would only be signed using the employee's private key, so if they desire, they can verify his key is valid on our public server.

3) ANY Mails detected coming from outside the corporation, would have extra line attached, saying "External mail" or something to that effect.

The advantage of working in that structure, would be that should an employee resign, get fired, betray, or his key stolen - it is easy enough to revoke its validity using the corporate main CA key. I am not sure yet how to do it exactly, but that works on GPG.

The disadvantage is of course, that ALL employees especailly the dumb ones, will be a big headache to setup encryption, and to ensure they encrypt every internal email.

I read these similar questions:

Best encryption client for Outook 2007/Exchange?

Looking for an email encryption solution

The second seem to be overly complex for our needs, but the Ironport sounded promising.. however I cant find anything relevant on their website - am I looking wrong?

I will also mention, that we are running a Datacenter, so a solution has to be one we can integrate on our premises.

So, what do you think people? and any suggestions? :)

Carmageddon
  • 152
  • 1
  • 9
  • The Ironport Encryption Appliance (IEA) product page is http://www.cisco.com/en/US/products/ps10602/index.html. If you want more technical info the configuration guide for the device is http://www.cisco.com/en/US/docs/security/iea/iea6.5/IEA_Configuration_Manual_v6.5.pdf. If you are already heavily invested in pgp, read the OpenPGP section of the config guide. The IEA has some good features surrounding pgp. – TimS May 11 '11 at 03:08

1 Answers1

1

There was a dream a few years back that everyone would start doing encrypted mail. Email clients started supporting things like S/MIME and PGP. It turned out to be a nightmare. Any security solution that relies on users doing something extra to make it work fails most of the time. Expecting end users to understand private keys and public keys and encryption is really asking too much.

A couple of common solutions emerged though that get around these issues.

First, you can do TLS. If there's an organization that you do a lot of business with and you want secure email between your company and theirs, you can negotiate a TLS arrangement with their email guys. How you implement this depends on your mail system but the end result is that you can enforce TLS between your two sites. At the same time, you can configure your outgoing MTA to attempt TLS to any external site. If they support it, it gets used. If not, regular non-encrypted SMTP is used. This is often referred to as 'opportunistic TLS' and has become very common.

Second, many email security packages now support some sort of encrypted outbound web gateway. You mentioned Ironport. That's one option but there are others like Tumbleweed. Most of the hosted SMTP gateways do this too (Postini/Google, MessageLabs, etc). In this scenario, outbound mail goes through the system or service and specific messages are flagged for 'security required' where they are diverted to a web-based system that sends a notification of a secure message and they click on a link and go read the secure message on a web server and can reply to it there. There are a lot of options for how these messages get flagged as requiring security. Usually you have some ability to create filters that scan the message body for things like social security numbers or credit card numbers or whatever. Typically users can also force a message to go secure by putting a specific phrase in the body of the message.

I'm sure there are other options that aren't occurring to me at the moment but these two are pretty common and worth exploring.

icky3000
  • 4,718
  • 1
  • 20
  • 15
  • Thank you! I will speak to the IT guys regarding Opportunistic TLS negotiation, but this does not solve the core problem: We want our INTERNAL emails that are being sent inside the corporation's domain and via exchange server, to be sent ENCRYPTED, because if security is compromised, sensitive material is only visible encrypted, unless of course the relevant public key is also compromised... – Carmageddon May 12 '11 at 21:55
  • You're right - nothing I mentioned above addresses the internal security. I'm sure there are some alternatives there but I'm less familiar with that requirements. I guess having users do encryption at the client level would work for that but as I said, those deployments often get messy quick. I'm not coming up with any other obvious answers for you. – icky3000 May 13 '11 at 00:06