E-mail requirements change for a safe use in the post PRISM internet

English: SMTP transfer model Blue arrows can b...
English: SMTP transfer model Blue arrows can be implemented by SMTP variations (Photo credit: Wikipedia)

Recently is mounting a serious concern about e-mail use and misuse, after PRISM the question is if e-mail can still be used as a safe communication media both for personal and enterprise use.

This is a difficult question since e-mail has always been a low security- high risk area in the enterprise as well as in the private world. When talking about mail we should remember what email really is:

Email is a simple method to transfer information from a computer to another, the used protocol SMTP is a plain text protocol that pass all the information in clear text. this means anyone can read the command and data sent if sniffing the line. data that are not in plain text are transformed with MIME that allow to change bitstream into ascii stream.

Another point we should consider is that email require an Email server to deliver information to destination, and this server is the database containing the message for the user. to allow the user to read those message heshe has to use a client and another protocol like IMAP or POP. the client allow the user to read the mail, store in another place different form the server, and provide conversion for mime data to be able to read rich data we are used to exchange.

this structure has been created not to preserve privacy but to provide a simple but effective way to communicate. SMTP does not contain any security feature, all the security needed should be create around an email communication process. But is this possible?

since email provide poor security basis we should try to work on several layer in order to make this communication channel a little bit more secure.

the areas we should work on are at least

 

1) user identification

2) server identification

3) server hardening (and storage level encryption)

4) mailstore hardening (and mailbox level encryption)

5) data transport encryption (Securing SMTP)

6) data encryption (user level encryption)

 

User Identification:

This is a serious problem in the email world, since transmission of data can start from any source and basically anyone can send an email using a simple telnet to a mail server impersonating anyone.

User identification is not provided by sender recipient data since those data can be easily forget, think about spam as an example or better phishing and scams.

An email solution should be able to provide a way to identify the user, but this require to be able to certify somehow the entire dataflow. email encryption solution can provide several layer of identification that can be used to solve this problem.

Server Identification:

this is an area where some progress have been done: SPF, DKIM, VBR and DMARC should be always implemented even if they required an extended deployment that is far from real.

Server hardening:

this is a tough area as well, a mailserver contain precious and delicate data that should be protected from intrusions, harvest attack, ddos and so on. In order to protect a server several techniques should be used like shutting down the non necessary serviceprotocols, check user and service rights and the other specific platform hardening , beside a NGF firewall, a secure mail gateway should be used to be exposed to the internet in order to limit the data exposure. but AV and protection systems should be added both to the host server and the mail services.

mailstore hardening:

this is a key point, even if you think your server and your email services are secure is better do not trust anyone so encrypting the store should be a must, i do not mean disk encryption, that is part of the server hardening, but the store encryption is a second layer that should be independent from the storage.

You can think about this need better if you consider data in the cloud, although you do not have idea where your data reside encrypting them in an independent way from the cloud provider will give you a little extra layer of security. No matter if  the cloud provider claim they use encryption, since you cannot control the keys it is useless from your point of view.

data transport encryption (Securing SMTP):

if you’re using an esoteric protocol probably do not need this passage, but since SMTP is the unsecure protocol we talked before we should try to provide at least a minimum layer of security, the easiest way to provide this is to use TLS to encrypt the SMTP communication. Most mail servers nowadays use opportunistic TLS configuration, that means use TLS if you can or go plain. I strongly suggest for secure communication to use always on TLS.

Data encryption:

This is the basis of any secure communication, you should always encrypt communication if you consider them critical or private. an encryption system should be able to use asymmetric key encryption as PGP. the problem here is that encrypting an email require a certain level of knowledge from both sender and recipient side. there are simple or hybrid encryption services that can provide a minimum level of privacy with a easy to use impact on the sender and the recipient.

again the key management is a fundamental requirement when using user level encryption, if you can’t control key exchange then you cannot provide a minimum level of security to your mail communication.

At the end the system will not be impenetrable but will give, if correctly implemented, a quite nice level of security, considering where we started from. we should remember anyway that when encrypting at user level we work on the mime part of the message so, at least sender and recipient and other data can be anyway retrieved.

for any further suggestion (protocols, implementation hints and so on) just send me a note.

cheers

 

Antonio

 

 

 

To the official site of Related Posts via Taxonomies.

CC BY-NC-SA 4.0 E-mail requirements change for a safe use in the post PRISM internet by The Puchi Herald Magazine is licensed under a Creative Commons Attribution-NonCommercial-ShareAlike 4.0 International License.