Best Practices for Business Class E-mail: Encryption, Authentication, and Control

Similarities Between Standard E-mail and Postcards

E-mail, the most important collaborative tool used in business today, shares many attributes with the postcard. Although the postcard and e-mail are used to send messages, it may be difficult to see similarities beyond this basic one. From a security standpoint, however, postcards and e-mail are quite similar.

Table 1. Comparison Between Postcards and E-mail

Security Characteristic Postcard E-mail

Message Security

The message is written on the back of the card and can be easily seen by anyone handling the postcard.

SMTP-based e-mail typically travels over the Internet without encryption.

Message Tampering

Someone other than the sender can easily add more text to the back of the card.

Because e-mail lacks hash verification, someone other than the sender can tamper with it.

Sender Authenticity

No sender check is done, nor is sender information necessary.

Sender information can easily be spoofed.

Recipient Authenticity

Although the postal system diligently attempts to place the card in the right mailbox, after that is done, anyone who has access to the postcard can see the message.

Though the e-mail system will deliver e-mail to the right address, an e-mail can be snooped by someone else if the e-mail client is not secure.

Message Control

When the postcard is sent, it is gone.

When the e-mail is sent, it is typically gone. And, although recall techniques exist, they often fail.

 

Based on these similarities, the comparison between postcards and e-mail is disturbing, particularly given the increasing requirement for security and control over any type of corporate communication.

Similar to the postal system, which has different classes of service for physical mail, such as a postcard, first class, and registered mail, e-mail should also have an elevated class of service. E-mail that is appropriate for business ('Business Class E-mail') should have the following attributes:Confidentiality:  Only the e-mail recipient should be able to read the message.

  • Message Integrity: The message should be tamper proof.
  • Sender Verification: The receiver should feel confident that the sender is legitimate.
  • Receiver Verification: The sender should feel confident that the message is viewable only by the intended recipient.
  • Message Control: The sender should always have control of the content and have the ability to retract the message.
  • Message Audit Trail:  The sender should be able to know who read the e-mail and at what time.

This document discusses ways to achieve this higher class of e-mail service using IronPort technology. Guidance is offered on when to use certain technologies as well as a discussion on the associated caveats and limitations.

Note:  There is no single solution to security, and ever-increasing levels of security may come with financial or operational costs or both. In addition, increased levels of security can be difficult to implement and may result in the failure of a message being successfully delivered and read. Therefore, when considering overlaying layers of security, it is important to understand the level of security the message requires and only apply what is appropriate.

Business Drivers for Business Class E-mail

The business requirements that drive messaging security come in one of two forms:

  • Messaging security to satisfy internal governance requirements
  • Messaging security to satisfy external compliance mandates

Internal governance requirements are the set of security rules and policies that a business develops in order to mitigate risk. Examples include message security for intellectual property protection, or message security when communicating with customers. Because these internal governance requirements can be discretionary, the business must decide how far to enforce the requirements.

External compliance mandates for messaging security are relatively new and are the set of security rules or policies mandated by external entities on the business. These mandates may be dictated by federal or state government organizations or by business organizations. The difference between internal governance and external mandates is that external mandates are not optional and typically have financial penalties for non-compliance. Examples of external compliance requirements include the following:

  • Health Insurance Portability and Accountability Act (HIPAA): this act mandates that healthcare organizations cannot send patient information unencrypted over public networks (the Internet).
  • Payment Card Industry Data Security Standard (PCI DSS): this standard mandates that organizations that work with credit card transactions cannot send credit card information unencrypted over public networks.

Though HIPAA and PCI DSS are often cited as the standard examples for compliance requirements, they are limited to their industry. If organizations are not in the business of working with healthcare patient information or transporting credit card account data, such mandates do not apply. The increasing concern about identity theft has influenced individual states to become more proactive in protecting the personal information of citizens. Examples of this include Nevada Rev. Statute 597.970, Massachusetts 201 CMR 17.00, as well as laws that have been passed and will be implemented in the near future in Connecticut, New York and Texas. With compliance mandates now affecting all businesses in a particular geography rather than an industry vertical, the general requirement to support Business Class E-mail is becoming even more of a necessity.

Encryption Models

When thinking of message encryption, the first common assumption is that the message is encrypted at the point of creation (the sender’s desktop) and decrypted where the message is being viewed (the receiving station). However, several other encryption models are used more commonly. These models are differentiated where the encryption and decryption occur.

When considering the path that an e-mail takes from sender to receiver, three important zones of trust can be identified as follows:

  • The Sender’s Enterprise LAN
  • The Internet
  • The Receiver’s LAN

These three zones are connected together by Message Transfer Agents (MTAs) or the devices that proxy messages from the Internet to the internal network. In the case of the sender, the MTA is the IronPort C or X series secure e-mail gateway. In the case of the receiver, this is some other enterprise MTA or a public web e-mail system such as Yahoo! or Gmail.

The encryption requirement of the message dictates if a message requires encryption through each zone. The following table details the zones of trust for each encryption model:

Table 2. Trust Zones for Encryption Models

Encryption Model Sender's LAN Internet Receiver's LAN

Endpoint-to-Endpoint

Encrypted

Encrypted

Encrypted

Gateway-to-Endpoint

Clear

Encrypted

Encrypted

Gateway-to-Gateway

Clear

Encrypted

Clear

 

Gateway-to-Gateway Encryption

Gateway-to-Gateway encryption is achieved through a transport level encryption technology called Transport Layer Security (TLS). TLS is the successor to the SSL protocol and provides message encryption over TCP/IP connections. TLS use over SMTP is called Secure SMTP over TLS (STARTTLS).  

When a sender’s message is received at the sending MTA, the sending MTA negotiates a TLS connection to the next-hop MTA.  If the MTA negotiation is successful, it sends the message to the next MTA over a TLS tunnel.

A requirement for enabling TLS is that the IronPort secure e-mail gateway must have a current X.509 certificate from a valid certification authority. Although the IronPort TLS configuration allows for messages to be sent unencrypted if a TLS session fails to be negotiated, when used for compliance, the message must be sent encrypted ('TLS Required').

Advantages of using TLS Encryption

  • For senders and receivers behind TLS-enabled MTAs, TLS encrypted messages provide automatic, transparent encryption that requires no additional steps by the sender or receiver to encrypt or decrypt the e-mail.

Disadvantages of TLS Encryption

  • Using TLS requires the purchase, installation, and occasional renewal of an X.509 certificate.
  • TLS is configured on a destination domain basis. Although TLS is a preferred method between two business partners that have TLS enabled, TLS transport cannot be assumed when sending to arbitrary receivers, because it is unknown whether the receiving MTA will be TLS-enabled.
  • TLS encryption can only be insured between the sending MTA and the next hop MTA; there is no guarantee that the next MTA hop will be the last MTA hop.
  • Using TLS alone does not provide sender or receiver verification.

TLS encryption is an increasingly popular option to satisfy internal governance concerns of message security to trusted business partners. If only the messages within the scope of an external compliance mandate, such as PCI, HIPAA, are going to these TLS-enabled partners, then TLS also satisfies these requirements. For external compliance mandates, it should not be assumed that messages requiring encryption are only going to TLS-configured MTAs.  As a result, a more general method of encryption must be employed.

Gateway-to-Endpoint Encryption

The Gateway-to-Endpoint encryption model assumes that the transport between the Internet and the receiving client must be encrypted. Though this model does not place requirements on the next-hop MTA for decryption, it does assume that the receiving client has the capability to decrypt the message.

Despite several technologies in the industry that support endpoint decryption, the assumption in this document is that the technology being used is IronPort PXE Business Class E-mail. The only requirement on the end-point for decrypting a PXE Secure Envelope is that the end-station has a web-browser and connectivity to the Internet.

Advantages of Gateway-to-Endpoint Encryption

  • Provides general encryption to all web-browser capable endpoints.
  • Provides all the advantages of Business Class E-mail.

Disadvantage of Gateway-to-Endpoint Encryption

  • Unlike TLS, decrypting a PXE Secure Envelope requires an additional step to view the message.

When looking to satisfy general compliance mandates to an unspecified set of e-mail receivers, Gateway-to-Endpoint encryption using the PXE Secure Envelope is the best choice. The overhead on the sender and the receiver is minimal and the sender can be confident that the message will be encrypted until a verified user wants to view the content.

Endpoint-to-Endpoint Encryption

The final and most aggressive model of encryption is Endpoint to Endpoint encryption. This model is used when it cannot be assumed that the sender’s LAN can be trusted and that the message and associated attachments need to be encrypted before leaving the sending station.

As encryption is being done on the sender’s station rather than the C-Series box, the sender must install the IronPort PXE Encryption Plug-in (for Outlook or Lotus Notes).

Advantage of Endpoint to Endpoint Encryption

  • Provides the highest level of encryption with the additional benefits of Business Class E-mail.

Disadvantages of Endpoint to Endpoint Encryption

  • Makes centralized sender message archiving slightly more complicated because the encrypted message is archived instead of the clear-text message.
  • Requires the sender to install a plug-in on the client.

The Endpoint-to-Endpoint encryption model is typically used for very restrictive internal governance mandates such as the protection of very sensitive intellectual property.

IronPort PXE Secure Envelope Technology

The need for encrypting e-mail is nearly as old as e-mail itself. As such, there have been several successive yet unsuccessful generations of encryption technology. As mentioned earlier, perfect security does not come without cost. The failure of previous models to become widely adopted is because these technologies made users or administrators change the way they worked with e-mail. Fundamentally, if an encryption technology dramatically changes the way users send or receive e-mail, it will not be adopted by the majority.

Two common but not widely adopted e-mail encryption technologies are:

  • Public Key Infrastructure- (PKI) based encryption
  • Secure Webmail- (or pull-) based encryption

PKI-based approaches (S/MIME and PGP) failed to achieve widespread adoption because of the requirement for certificate exchange and management. Acquiring, installing, and managing certificates have limited PKI-based encryption implementations to internal group-to-group communications.

The secure webmail or 'pull' model is simply the implementation of web-based mail on an enterprise portal. This technology is a commonly used approach for large business to consumer-based businesses such as banks. However, this method of secure encryption failed to reach wide-spread adoption because it forces the recipient to retrieve e-mail by going to the portal. This type of encryption changes the normal method of e-mail receipt.

Noting the failure of wide-spread adoption of technologies such as PKI- and pull-based encryption, in order for an encryption technology to succeed, it must:

  • Minimize the end-station requirements for decrypting e-mail.
  • Not change the way the user accesses their e-mail.

With these design criteria in mind, the PXE architecture works as follows:

Figure 1. IronPort PXE Architecture

 

The following is the IronPort PXE process:

  1. All e-mail leaving the organization is routed through the IronPort Secure E-mail Gateway.
    • Through a variety of tagging or inspection methods, the IronPort Secure E-mail Gateway determines if the e-mail should be encrypted. If so, the e-mail is internally directed to the PXE encryption engine embedded in the Secure E-mail Gateway.
    • The PXE engine in the Secure E-mail Gateway renders the e-mail message in HTML and encrypts this along with any attachments to the original e-mail into a secure HTML payload (called the PXE Secure Envelope). The message-level key for the Secure Envelope is sent to the Cisco Registered Envelope Service (RES) for long-term storage and later automatic retrieval to open the message. Cisco RES is a Cisco-maintained 'software as a service' specifically for storing message keys.
    • The PXE Secure Envelope is attached to a notification e-mail and is sent to the recipient.
  2. The recipient receives the notification e-mail and is directed to double-click on the PXE Secure Envelope to start the decryption process through a web browser.
  3. The recipient is prompted to enter their login credentials, authenticating that they are the intended recipient. When the user is validated by Cisco RES the per-message key is automatically sent to the browser.
  4. The message is decrypted and displayed to the recipient.

Advantages to PXE Secure Envelope

  • Secure messages are delivered to the client in the manner they expect (by means of their e-mail client).
  • The only requirement is that the end system supports a web browser (unlike PKI-based approaches that require certificates) and an Internet connection.
  • Unlike webmail where the content is stored in the cloud, the recipient owns the content.
  • The per-message keys are managed and maintained as a cloud service. Keys are maintained for at least 10 years after encryption.

Though the C-Series as the encryption engine and Cisco RES as the key store is the most typical deployment scenario, other options exist. If an organization does not want the per-message keys stored as a cloud service, an additional IronPort appliance called the IEA Appliance can be purchased and installed locally to serve as a local key store. Further, if the organization already has an MTA other than the IronPort MTA or requires special modifications to the envelope, then the IEA can also be used as the PXE encryption engine. Finally, if the organization wants to implement the Endpoint-to-Endpoint encryption model, then the PXE Outlook Plug-In can be installed on the sender’s workstation; a plug-in is not required for the receiver.

E-mail Control

Because every PXE Secure Envelope has an associated per-message key stored on Cisco RES and the registered recipient must be logged into Cisco RES before the PXE Secure Envelope can retrieve the key, the sender maintains a tremendous amount of message control and visibility.

Each sender that uses PXE has the ability to manage their sent e-mail through the PXE User Portal. From this console, PXE senders are able to know who the recipients are and when they opened the e-mails. Furthermore, PXE senders are able to expire their message keys; in other words, they can effectively 'recall' the e-mail. A PXE Secure Envelope that is blocked from accessing its key is effectively recalled.

Figure 2. Cisco Registered Envelope Service Administrative Portal

 

Additional Options for Increased Accessibility

Two requirements for a user to be able to open PXE Secure Messages include having Internet access and having an account on Cisco RES for authentication. If either of these conditions is unreasonable for a particular use-case, they can be over-ridden, albeit at the cost of decreased security.

PXE Secure Envelope Off-line Mode: This configuration mode allows the user to store the per-message keys as an encrypted browser cookie after they authenticate. The advantage is that when the user wants to subsequently open the message after the cookie is stored, Internet connectivity is not required. The disadvantage or security compromise is that the sender loses control of the e-mail, which means they cannot 'expire' or lock the message.

PXE No-Authentication Envelopes:  With a No-Authentication Envelope configuration, there is no requirement for a Cisco RES account to open the envelope. Although the message will still be transported over public networks encrypted, anyone who has access to the PXE No-Authentication Secure Envelope, whether on the recipient’s station or through a forward, can open the envelope. Though the sender can still expire or recall the message, they will not be able to know who has opened the message.

Mitigating Phishing

Phishing is the fraudulent attempt to acquire passwords and financial information by masquerading as a trusted organization in an on-line environment.  In general, almost all on-line transactions that require login can be susceptible to a phishing attack. Although steps can be taken to minimize the possibility of phishing, the best defense against a phishing attack is to be aware of what phishing is in order to detect the obvious signs as well as thwart phishing attempts.

In the specific case of a PXE Secure Envelope, a phishing attempt may be to send a forgery of a PXE Notification Envelope to a recipient in order to maliciously retrieve their Cisco RES login credentials. If a malicious user has the Cisco RES login credentials and has access to the user's PXE Envelopes, they will be able to decrypt the secure messages.

The following are three ways to combat phishing:

  • Educate users to be aware of what a proper PXE Notification e-mail looks like.
  • Use the PXE Secure Envelope’s Personal Security Phrase.
  • Use Domain Keys Identified Mail (DKIM) and Sender Policy Framework (SPF) way to validate the e-mail sender (sender authentication).

Note: There is no guarantee to email security, particularly when it involves a judgment call from the receiver on whether the email is valid or not. However, adding additional layers of security does help. Phishing is a problem to which all authenticated web-based transactions are susceptible. Much like locking your house, the goal of security is to make an exploit difficult for the perpetrator, causing them to move on to another and more easily exploitable target.

User Education

An e-mail recipient that understands the dangers of phishing and is aware of the common techniques that phishers use can be one of the best defenses against a phishing attack.  Unfortunately, unlike technology-based solutions, there is no guarantee that receivers will read training materials or heed the guidance such materials offer.  When deploying a service like this, common strategies for education include sending out an email to potential recipients that discusses the service and educating users about what an envelope should look like, or provide a link in the PXE notification email directing the recipient to receiver documentation.

PXE Secure Envelope Pass-Phrase

The Personal Security Phrase is a commonly used anti-phishing technique and displays a user-configured catch phrase to the user, one that only the user would know. In the following example, the Personal Security Phrase 'I’m a PC' was a preconfigured phrase that is only known by Cisco RES and the user. In order for a Personal Security Phrase to be displayed, the user must have the secure cookie enabled on their PC. A common issue with the security phrase approach is that if the user tries to access the secure envelope on a different computer, or if the cookie was erased, the pass-phrase will not appear. Pass-phrase effectiveness will depend on an aware receiver.

Figure 3. Cisco Registered Envelope Service Pass Phrase Envelope

 

Sender Authentication

Another method to thwart phishing attempts is to validate who sent the envelope with the assumption that a known sender would not try to exploit the person to whom they want to send legitimate e-mails. Two standards-based technologies that IronPort supports to accomplish this are DKIM and SPF.

DKIM is a method for e-mail authentication, which allows a person who receives e-mail, to verify that the message actually came from the domain that it claims to be from and that the message has not been altered. The basic premise behind DKIM is that the sending MTA makes a hash of the message using a private key and appends the hash to the header of the e-mail. The receiving MTA or e-mail client uses the public key for the domain, accessed through DNS, to validate that the sender is legitimate. Although not an excellent method of sender domain validation, DKIM depends on the receiving MTA or client to have DKIM enabled and the user to know to look for DKIM validation.

SPF allows e-mail relays and MTAs to validate which systems are allowed to send e-mails from a particular domain. SPF stops forged sender addresses from arriving from non-authorized sending systems.

Conclusion

Because e-mail is widely used for business communication, it is surprising that “Business Class E-mail” features have not been built directly into e-mail protocols. E-mail is likely a victim of its own success. Because SMTP is so widely used, the evolution of e-mail remains a slow process. However, technologies such as PXE Secure Envelope, DKIM, SPF and TLS can address the requirements for Business Class E-mail and overlay seamlessly on top of SMTP. And although these technologies are not perfect, judicious and appropriate use of these techniques, in addition to sender and receiver education, can assist with a secure and robust e-mail solution.


This document is part of the Cisco Security Center.

This document is provided on an "as is" basis and does not imply any kind of guarantee or warranty, including the warranties of merchantability or fitness for a particular use. Your use of the information on the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document at any time.

Back to Top

Cisco Security Center