Similarities Between Standard Email and Postcards

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

Table 1. Comparison Between Postcards and Email

Security Characteristic	Postcard	Email
Message Security	The message is written on the back of the card and can be easily seen by anyone handling the postcard.	SMTP-based email 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 email 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 email system will deliver email to the right address, an email can be snooped by someone else if the email client is not secure.
Message Control	When the postcard is sent, it is gone.	When the email is sent, it is typically gone. And, although recall techniques exist, they often fail.

Based on these similarities, the comparison between postcards and email 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, email should also have an elevated class of service. Email that is appropriate for business ('Business Class Email') should have the following attributes:

Confidentiality: Only the email 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 email and at what time.

This document discusses ways to achieve this higher class of email 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 Email

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 Email 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 email 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 email gateway. In the case of the receiver, this is some other enterprise MTA or a public web email 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 email 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 email.

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 Email. 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 Email.

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 email 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 Email.

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 email is nearly as old as email 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 email. Fundamentally, if an encryption technology dramatically changes the way users send or receive email, it will not be adopted by the majority.

Two common but not widely adopted email 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 email by going to the portal. This type of encryption changes the normal method of email 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 email.
Not change the way the user accesses their email.

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

Figure 1. IronPort PXE Architecture

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 email, 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 email 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 email 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 email 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 emails. Two standards-based technologies that IronPort supports to accomplish this are DKIM and SPF.

DKIM is a method for email authentication, which allows a person who receives email, 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 email. The receiving MTA or email 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 email relays and MTAs to validate which systems are allowed to send emails from a particular domain. SPF stops forged sender addresses from arriving from non-authorized sending systems.

Conclusion

Because email is widely used for business communication, it is surprising that �Business Class Email� features have not been built directly into email protocols. Email is likely a victim of its own success. Because SMTP is so widely used, the evolution of email remains a slow process. However, technologies such as PXE Secure Envelope, DKIM, SPF and TLS can address the requirements for Business Class Email 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 email solution.

This document is part of the Cisco Security portal. Cisco provides the official information contained on the Cisco Security portal in English only.

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 in the document or materials linked from the document is at your own risk. Cisco reserves the right to change or update this document without notice at any time.

Best Practices for Business Class Email: Encryption, Authentication, and Control

Contents