E-Mail In Peril

Mar 28, 2008 (08:03 PM EDT)

Read the Original Article at

E-mail as we know it is under duress. Ever-increasing loads of spam--estimated at up to 98% of all e-mail--is drowning out the messages business users need to see. Highly targeted phishing attacks are making news and leaving customers and employees jumpy. And for IT, concerns about sensitive data traveling the Internet unencrypted mean valuable e-mail business uses aren't even being considered.

We spoke with a variety of security vendors to see if there's any hope. Big trends include e-mail security in the cloud, led by Google's Postini; use of cryptographic signatures to thwart phishing; advances in encryption and key management; and merging of data leak prevention with mail systems.

InformationWeek Reports

One surprising finding is that the days of software-only e-mail security appear to be coming to an end. Even Sendmail, a descendant of the Internet's original Message Transfer Agent that has long been distributed as both open source and proprietary software, is now moving to an appliance model. Sendmail CEO Don Massaro ascribes this shift to simpler installation and integration as well as performance gains over software installed on commodity hardware and a stock operating system.

You don't just need to secure e-mail: IM is also proving a vector for data loss. We discuss how to stay safe.

Form factor isn't the only place we're seeing evolution. Last week's--or even yesterday's--spam-control techniques can't keep up with constantly increasing attacker sophistication (see Our Take: Any Spam is too Much). As in the security infrastructure, spam-control vendors are banking on multilayered defenses. Barracuda Networks' Spam Firewall filters messages through 11 layers, while Sendmail employs an "anti-spam cocktail," where many individual tests combine to give messages a "spamminess" score, says Greg Olsen, the company's director of product management.

In the past, a significant portion of the anti-spam arsenal involved blacklists and greylisting, but the efficacy of those tactics has decreased, forcing vendors to add new twists. Replacing, or at least augmenting, blacklists is the concept of reputation. Using their vast reach into the Internet mail stream, vendors track the IP addresses sending e-mail. Addresses known to send large amounts of valid mail don't need to be checked as thoroughly, but a node that suddenly starts spewing millions of messages would warrant suspicion. Where an older system might have used greylisting to simply delay delivery of all e-mail in the hopes the spammer wouldn't bother resending, today's systems selectively delay mail from nodes believed to be sending spam, or throttle the bandwidth available to those it's unsure about, until a decision is made.

Once a connection has been accepted, messages are individually scanned. The companies we spoke with perform extensive analysis, though not by trying to interpret a message's meaning, as in the past. While vendors are leery of sharing specifics, they all scrutinize thousands of attributes of a message and compare them against those found in millions of other messages to identify common elements in spam.

Impact Assessment: E-Mail Security

(click image for larger view)


E-mail security as a service is becoming an increasingly popular choice. Google's recent repositioning of its Postini service, moving to simplified plans and pricing, exemplifies this trend. Postini's entirely online process means IT can sign up, reconfigure DNS to route e-mail through the Postini service, and be protected in about 15 minutes.

But ease of implementation and eliminating physical hardware aren't the only benefits of filtering spam in the cloud. With more than 2 billion messages passing through Google's servers every day, the company has a tremendous capability to correlate message patterns and react quickly to new threats, says Adam Swidler, Postini's marketing manager.

Even companies selling e-mail security appliances offer benefits of the cloud computing model. Barracuda, Cisco's IronPort, and Sendmail have incorporated features that benefit from their large installed bases. In Barracuda's case, information about mail flow and message characteristics (not the messages themselves or identifying information that could jeopardize confidentiality) are sent to Barracuda Central, where engineers analyze patterns looking for new forms of spam and viruses that existing systems can't catch. They can then push updates to all their appliances within 30 minutes, hopefully catching outbreaks before they spread far.

As people move their financial lives online, phishing is becoming increasingly lucrative. In the latest twist, online criminals are personalizing their attacks. This tactic, sometimes referred to as "spear phishing," involves sending a limited group of people--say, employees of a specific company--a message that is made more convincing with the use of specifics. A recent example of this was a spate of mail sent to students at various universities, designed to look like it came from the school's help desk.

The problem of reliably identifying the true sender of e-mail is so intractable that many businesses tell customers that they will never communicate via e-mail. Microsoft, for example, announced several years ago that it won't send patches via e-mail, and the Internal Revenue Service has repeatedly warned that because of the prevalence of forgery, it will never initiate e-mail contact with a taxpayer. But this prohibition eliminates a useful business tool that can save money and resources versus sending paper correspondence.

Fortunately, there are advances that aim to more reliably identify whether e-mail comes from a legitimate sender. In May 2007, the Internet Engineering Task Force approved a standard for Domain Keys Identified Mail, which embeds a cryptographic signature in the header of an e-mail to verify that the message is legit. The value of the standard is in protecting a brand's reputation by assuring users of a message's source. This is crucial when using a third party to send e-mail, because earlier methods, such as SPF and Sender-ID, relied on authenticating the IP address of the e-mail server.

Eventually, sender authentication will help with the spam problem as well, once mail servers can reject messages lacking proper or matching authentication. All the vendors we spoke with are heavily involved in this effort--Sendmail is partnering with Karma Sphere for reputation scoring--but it will probably take years for sender authentication to have a significant impact.


We've all been frustrated at missing out on some advantages of e-mail, but caution is understandable: Besides worries over e-mail getting lost in the flood of spam or that phishers will forge messages, companies are concerned that sensitive data, like monthly statements, could be intercepted, compromising privacy and even leading to fraud.

Early systems from e-mail vendors, including PGP, involved gateways that intercepted and held messages. A gateway would send a brief e-mail to the user directing her back to a Web portal to read the message. But that's a hassle, and it prevents the user from archiving the message for future reference. E-mail companies have been trying to find better solutions.

Most have developed technologies to wrap an encrypted message in an HTML page, with the JavaScript code to decrypt it included. The idea is that an HTML-aware mail client or a user accessing a Web mail service directly through the browser will be able to decrypt the message within the usual mail-handling routine. We had vendors send us samples of messages encrypted in this way, and while we eventually were able to read them, all took multiple steps and were far from the seamless experience we'd hoped for.

The No. 1 difficulty: key distribution. Traditional e-mail encryption has relied on public key cryptography, where there's an exchange of keys before e-mail is sent. This is handled either through a PKI infrastructure (in the case of S/MIME) or publicly accessible key servers (with PGP). The overhead and complexity inherent in these approaches have discouraged many companies from implementing e-mail encryption, especially for outside communications. The current generation of clientless encryption systems deals with the key problem by storing keys on the mail server and having the recipient connect back to obtain the key or register for a passphrase to unlock the message. This approach has a business bonus: Requiring the user to connect back to the mail server provides a chance for the company to cancel or revoke a message by denying access to the key or password, and it can also track when the message is opened. Cisco's IronPort and Google's Postini don't even require the company to manage the key infrastructure, but instead provide this in the cloud.

Sendmail uses Voltage's identity-based encryption scheme, which sends an encrypted message to the user along with a Web page that posts the encrypted portion back to the sender's Sendmail appliance for decryption. After authentication, the user receives an SSL-encrypted Web page containing the message in plain text.

For its service, PGP has worked with Adobe to embed messages in encrypted PDF files. PGP estimates that upward of 90% of Internet users have the ability to view PDF files, streamlining the process for the recipient. There's still the difficult problem of password delivery, however, requiring a connection back to the server. This approach is well suited to situations where the sender and recipient already have established a relationship and exchanged passwords. A great example would be a university delivering grades to students via e-mail, where encryption can use an existing password rather than generating a new one. PGP says it's actively working on this sort of integration for future releases.

Despite the difficulties, the rewards of being able to instantly deliver confidential information and the potential cost savings of moving from postal mail to e-mail will drive vendors toward further innovation that will likely solve the current limitations.


Once the "how" is worked out, mail systems must decide which messages are to be encrypted. In the case of bank statements and medical data, that's simple. But the big trend here is that vendors are merging data leak protection, or DLP, functionality into their e-mail systems, letting IT establish rules to encrypt messages when the content warrants. Using DLP techniques, rules can be keywords and/or regular expressions. Some products even include the ability to fingerprint key data files, so the mail server can recognize them and either encrypt them or refuse to send the e-mail.

Of course, another option is to encrypt everything. All of the vendors we talked to support SMTP-Transfer Layer Security to encrypt the entire data connection between mail servers. The benefit of this approach is that it's seamless to users while protecting all data in transit. The downside is that IT can reliably count on SMTP-TLS working only with established partners. When encryption is essential, you must configure the mail server to refuse to send to servers that don't support SMTP-TLS.

Also, because SMTP-TLS protects mail only in transit between mail servers, messages are subject to interception if there are intermediate stops outside the control of either party, such as an ISP relay. Messages are in plain text when stored in the recipient's mailbox, so the receiving party needs to understand the risk if its mail server were to be compromised. This isn't to say SMTP-TLS isn't useful, but as with all types of security, it should be just one link in the chain.

Continue to the sidebar:
Our Take: Any Spam is too Much