Contents
Similarities Between Standard E-mail and Postcards Similarities Between Standard E-mail and PostcardsE-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
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.
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-mailThe business requirements that drive messaging security come in one of two forms:
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:
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 ModelsWhen 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:
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
Gateway-to-Gateway EncryptionGateway-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
Disadvantages of TLS Encryption
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 EncryptionThe 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
Disadvantage of Gateway-to-Endpoint Encryption
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 EncryptionThe 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
Disadvantages of Endpoint to Endpoint Encryption
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 TechnologyThe 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:
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:
With these design criteria in mind, the PXE architecture works as follows: Figure 1. IronPort PXE Architecture
The following is the IronPort PXE process:
Advantages to PXE Secure Envelope
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 ControlBecause 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 AccessibilityTwo 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 PhishingPhishing 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:
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 EducationAn 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-PhraseThe 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 AuthenticationAnother 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. ConclusionBecause 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.
|
|||||||||||||||||||||||||||||||||||
