I have spent a lot of time recently with a “major Wall Street financial organization,” looking at Data Leak Prevention (DLP) tools and, specifically, how the Compliance component of Sendmail’s Mailstream Manager milter stacks up against their existing tool, a leading DLP vendor’s flagship product.

Before getting into the details, it is important to understand that Sendmail doesn’t claim to replace DLP products.  A true, full-featured DLP implementation looks at all egress points from the Enterprise (as well as intra-company data transfers, data at rest, and any number of other things) and applies company policies as appropriate to protect confidential information.  Sendmail, on the other hand, primarily looks at email — either at the routing layer or at the gateways (or both.)

Numbers I have seen, though, suggest that as much as 80% of data leakage occurs via email — simple things like employees emailing work home so they can extend their work day, or setting Outlook to send a copy of their mail to their Blackberry.  Whatever the cause, a lot of “stuff” that a company doesn’t want to let out leaves via email.

So this “major Wall Street financial organization” has looked at what they are actually monitoring, what they really care about, and how they are doing their jobs, and they’ve come to the conclusion that more effectively monitoring outbound email is mission critical.  As a result, they invited us in to show what we can do in a proof-of-concept.

Banks, particularly large international banks, have a really tricky compliance model.  Things that are okay in Dallas are illegal in Paris and things that are of concern in Singapore might be happening in London.  Keeping track of the various laws and regulations, as well as how they are enforced and the penalties for failing to follow the rules, is the full-time job of a whole group of lawyers literally around the world.  Fortunately for Sendmail, all we have to do is provide a flexible framework against which the bank’s compliance team can build, test, and deploy policy rule-sets that implement the compliance model… That, in a nutshell, is what Mailstream Manager is.

The DLP vendor we were competing against utilizes an interesting technique to intercept email — they use the SPAN port of the gateway router to copy every packet to their device.  The packets are collected and assembled on the device. Once the message is recreated, it is run against the policies and their very robust interface will allow compliance officers to take action.

I see a few weaknesses in this model — some are inescapable, and some, I suppose, can be circumvented.

The weaknesses I see include the fact that messages that leave the gateway mail server using TLS or messages that are encrypted prior to transmission (Voltage, PGP, etc.) cannot be read and are therefore cannot be scanned.  Additionally, messages that are captured on the SPAN port have already been delivered out of the Enterprise before you spot the violation. At best you can only reprimand the sender and train him not to send that type of information out in the future. At worst you’ll let confidential information out like Social Security numbers or Credit Card Numbers, for example.  The vendor does offer an inline solution (at considerable additional expense), but the bank’s messaging team, justifiably, does not wish to have a black-box touching each message that goes out.  DLP vendors are not MTA vendors. I also question the ability of any single device to keep up with the huge processing requirements necessary to reconstruct and monitor the packets of a multinational bank’s internet traffic. In our test environment, it simply missed some messages. In fairness I am told that the production interfaces and appliance hardware are considerably more powerful and this type of dropout does not occur.

In any event, the Sendmail approach is to do the DLP processing as a component of the message transmission (making DLP a messaging application.)  This overcomes many of the weaknesses identified above and allows us to help the bank reduce architectural complexity, and implement more robust policies.  Since the Sendmail server sees the message prior to any enterprise encryption, and prior to entering the TLS tunnel, those concerns are eliminated.  As every message goes through a Sendmail server, we don’t have to worry about missing a message (or having the horsepower on hand to reassemble the packet stream.)  Because we have the ability to queue messages, even during periods of unexpectedly high volume, we can meet the load.  Best of all, Sendmail is an MTA vendor, so the messaging team has confidence in our ability to properly manage the message.

The Proof of Concept required us to show the ability to selectively apply policies based (for our test) on the home country of the sender.  Additionally we had to show the effectiveness of our policies vis-à-vis the established DLP vendor.

Our approach was straight forward. 

Step one was to split off a copy of the message to operate against.  The original message was transmitted on out so the DLP vendor’s server could take its shot.

Next I configured the lab gateway server to do an LDAP lookup on the sender.  Based on the information returned I was able to identify the sender’s home country. I also grabbed the sender’s real name and the email address of his/her direct supervisor.

Third, the message dropped down through various high-recall policies that Sendmail’s policy guru, Daniel Hedrick), had built for the job — if we had a possible hit then the message was forwarded, based on the home country, to a high-precision server that managed country-specific policies.  Since most messages will not trigger a policy hit, this methodology allowed us to drop non-hit messages and increase performance at the gateway — considering that, in production, millions of messages a day will be looked at, even small performance increases are important.

The country-specific server performed a deep (high precision) scan on the message and either found a policy violation or not.  Again, we just dropped messages that were not in violation.

If there was a violation, we used the information obtained in the earlier LDAP lookup to do three things: 1) We sent a note to the sender informing them that their message was in violation of a specified policy (which we described) and how to avoid future violations; 2) we sent a note to the sender’s supervisor informing him of the violation and describing the nature (but not the content — in support of some of the draconian privacy laws in the EU) of the violation; and 3) we placed a copy of the violation (if it was severe enough) into quarantine and notified compliance of the violation.

Once we were done, we had a beautifully simple configuration that proved to be superior to the DLP vendor’s in their testing in the lab.  We were able to capture 100% of test violations with a considerably lower false positive rate than that of the DLP vendor.  Out of our pool of messages, the DLP vendor never saw about 10% of the messages (I found this to be important, but, as described above, the customer was certain that those results would not be seen in the production environment so that finding was discounted.)  Additionally, the existing DLP vendor had a very high false positive rate: in testing, if they identified 100 Social Security Numbers, 44 of them were not real social security numbers (66 were, and we identified all of them.)  We were able to predict, based on their rules, and then show in the lab, that we would reduce false positives dramatically. This is less impressive than it sounds as this drop in false positives is more a function of the effort placed into developing good policies than it is a reflection on the underlying technology.  I have no doubt that if our policies were translated onto their policy engine their false positives would drop as well. Having said that, I do find it fascinating that their core business is implementing polices and their policy sets were so poor that we were able to highlight dramatic differences. In practice high false positive rates cause the compliance team to discount lower-scoring violations because they are generally not worth the trouble to sort out.

In the end the customer was impressed.  It was their view that we were the technical equal, as far as implementing policies, to the existing DLP vendor in the email space.  We beat the DLP vendor with TLS and encryption issues and we beat the DLP vendor in terms of simplicity and flexibility.  When the customer considered the fact that moving from a monitoring solution to a blocking solution, where we would operate on the message itself rather than on a copy, was a simple matter of modifying a few policies at any point in the future versus modifying their architecture and deploying more new hardware for the DLP vendor, we again came out on top.  Our solution was also priced millions (literally) less. For Sendmail, DLP is an application within our framework rather than a standalone solution.

I believe we surprised the customer with how robust our product was.

Did we get the business?  I don’t know yet.  I do know that the Messaging Engineering Team, Compliance Engineering Team, Messaging Operations Team, and the Compliance Operations Team all endorsed Sendmail as a viable solution for their compliance monitoring and future enforcement needs.  I’d like to think that, if I were them, I’d select us regardless of costs — our solution was just more elegant but I might be biased.  With the current financial mess, the fact that we can save them a substantial amount of money, now and in the future, while meeting their technical challenges with a robust and elegant solution, should bode well for Sendmail.

I’d like to mention our most recently “live” customer project.  We have a customer whose business is to send high-volume opt-in outbound email.  (Think electronic newsletters, account statements and so on.)    The sending of high-volume mail is quite tricky as it turns out, so this might become a series of blog posts.  Who knows?   For now, I’d like to focus on just one part of it.

To efficiently send high volume mail outbound, you must look at what is not getting through.  This could include “account no longer exists,” “user over quota,” and other permanent or transient reasons why the message for a given user is not accepted by the mail server at the other end.

Our customer’s existing bounce handling system is a black box that has not offered all of the functionality required by the customer.  The black box vendor claimed (years ago) that by going with their solution, the customer would have an automated solution that meets their needs fully.   This would be great, if only it were true – and if only there were some way to measure that those claims were accurate.

Our job was to accept to set up a high-capacity front-line system for handling all of those bounces, auto-replies, and opt-out emails.   Everything is accepted by our Sentrion servers, and is then sent on to two different paths.  One email path is to send the original message on to the existing solution at the customer site, preserving existing functionality.   The other email path is that an exact copy of the original message is analyzed and then sent on to systems running the massively scalable Sentrion Quarantine server, an IMAP-accessible message store that provides automatic cleanup of messages once they are no longer needed.

 Since the “go-live” date, we have seen some interesting things by having the Sentrions between the customers and this black box solution.  This has allowed us to work together with the customer to fine tune their HA approach.  To better identify, track, process, and route the different types of email coming in.  In addition, we’ve begun the process of adding the new functionality this customer has been looking for.

The moral of this story.  

There’s benefit to putting a standard solution like the Sentrion between your customers and any kind of “black box” solution you may have.  This customer now has the visibility into the email process that they’ve been after for years – but without affecting the overall delivery or processing times.   

December 16th is the five year anniversary of the passage of the CAN-SPAM Act of 2003. For some, the act has been measured as a success as it has been used to successfully prosecute a number of cases. Unfortunately, it has not had a visible impact in protecting us from the ever increasing spam problem.

The Act mostly served to keep honest people honest and did not do anything to solve the spam problem. It made it easier for consumers to find contact information and opt-out of commercial e-mail sent by legitimate, law abiding, companies operating in the United States. However, the majority of the spam received is not from legitimate, law abiding, US companies. Because of this, laws will provide little protection against the junk mail problem.

In order to do that and make these laws enforceable, we need to invest in technical solutions. Some of those solutions are available today but aren’t yet widely practiced:

• Requiring Sender Authentication on all outbound mail

DomainKeys Identified Mail (DKIM) can be used to both validate the sender of the e-mail as well as verify the integrity of the contents against any tampering. Sending sites should begin DKIM signing all outgoing mail to provide proof of identity. Receivers can then be assured of the identity of the sending domain and prevent forgery. For this to work, receiving sites need to perform DKIM verification and end-user mail clients (e.g., Thunderbird, Outlook, etc) need to show the results of that verification. There are also other Sender Authentication methods available (SPF, SenderID, etc) that provide some protection against mail forgery. Having a verifiable sender is a vital requirement for making legal requirements enforceable.

• Domain-based reputation

Once Sender Authentication has provided a verified sender, the next step in fighting spam will be a domain-based reputation service to help identify “good” senders vs “bad” senders. Since even spammers can provide Sender Authentication on the mail they send (though without forgery), sites need to be able to separate the good from the bad based on that verified sender.

• Proper network etiquette

ISPs (both network connection providers and service providers, e.g., webmail providers) need to enforce outbound mail sending practices. This comes in two forms. For network connection providers, the first is to make sure they act as a mail and network gateway for outbound mail from their customers and block attempts to access other SMTP servers on the network. This will prevent zombies from flooding the Internet from machines that shouldn’t be sending out mail directly. Once this is in place, all providers then need to start providing anti-spam, anti-virus, and malware scanning on the messages they are sending out to the Internet just as they do today for inbound messages. This is similar to what they did years ago for egress routing to prevent customers from sending forged IP packets out on to the Internet. Proper network etiquette will be even more important with domain-based reputation in place as ISPs will need to protect their reputation so bad users don’t have a negative impact in their overall reputation.

There’s a lot of talk these days about “Cloud Computing,” the latest fad in IT. Of course most industry veterans view Cloud Computing as the new name for “managed services,” “software as a service” (SaaS), and even the old moniker of “timesharing” back in the old days. Cloud Computing makes a lot of sense for enterprises wishing to offload computing costs from their own data center and outsource the application to a service provider responsible for all the administrative hassles and costs of computing with a single fee.

In the email world, we’ve noticed many enterprise customers embracing cloud computing for inbound email filtering (e.g. handing Anti-Spam and Anti-Virus cleansing of the high incoming volumes of mail). This makes good business sense as Anti-Spam filtering has fast become a commodity application, and commodity applications are logical expenses to outsource vs. handle within ones own IT infrastructure. Once an enterprise discovers the attraction of cloud computing for lowering costs of filtering email, it is very common for them to suddenly recognize the importance of the core email backbone infrastructure which has supported the in-house email filtering applications.

At Sendmail, we have seen a rise in our business for modernizing the messaging processing infrastructure whenever an enterprise starts the analysis of cloud computing for email filtering applications. Often the value of complex routing and delivery of critical and important email is taken for granted by IT organizations looking to cut costs. Suddenly there is recognition that there has been an over emphasis on stopping unwanted email and little attention has been paid to guaranteeing the delivery of wanted mail to the right mailbox. Guaranteed message delivery is especially important for global organizations with multiple gateways in various locations, multiple domain names due to mergers and acquisitions or marketing promotions, and is essential to any enterprise with strict compliance regulations that must be followed. This makes the messaging processing infrastructure for central policy-based, directory-driven email a high-value need and it can easily be cost-justified for obvious “control” of IP.

Modernizing the message processing infrastructure may include embracing cloud computing for low value commodity applications but requirements for mandatory control of sensitive data will need to be managed on-site. Organizations concerned with preventing data leaks have to manage outbound mail content. Messages must be scanned, reviewed, and acted upon according to centralized policy.  Even incoming messages which have gone through the cleansing process via the outsourced cloud computing supplier, must be handled efficiently, and delivered, copied, archived or reviewed for accurate/speedy delivery on the premises of the enterprise. These higher value actions take place in a modernized message processing infrastructure that Sendmail provides with Sentrion® MP. Anyone investigating the merits of managing email in the cloud needs to take into account all the infrastructure requirements which are also a major component of the solution. I’d be happy to share our customer contacts to help in this analysis.

This podcast features Sendmail’s executive vice president and chief operating officer, Glen D. Vondrick, discussing complex routing such as per-recipient encryption, outbound messaging security, and handing multiple email domains.

Ask the Experts: Simple Routing versus Complex Routing

Over the many years I have been involved in high-tech marketing, I have learned that the best way to market a product is to tell your prospective customers how their peers and competitors are using your product to solve real problems.  Sendmail customers use our products to solve many different types of enterprise messaging challenges in many different ways.  Some of them are quite complex and require much more than the average email appliance can provide.

We challenged our team of messaging experts and Systems Engineers to document some of the more difficult customer challenges that they have solved using Sendmail’s products.  Let me give you a quick example:

A large Biotech Company required certain messages to be encrypted based on a number of different message attributes.  The Company had several concerns:
•    Regulatory compliance with the disclosure of company financials and other sensitive executive level documents
•    Concern for the rogue admin reading sensitive communication
•    Compliance with electronic filing requirements with the FDA
•    Recovery of encrypted data

Sophisticated policy-based message encryption and intelligent routing was the only viable way of ensuring that the correct encryption policies were applied to messages.

Using Sendmail’s policy engine and integration with their LDAP directory, the policy sets make the determination as to what messages get routed through the encryption server for message encryption.  LDAP look-ups and deep content scanning are used to determine which messages need to be encrypted. For example:
•    All executive email must be encrypted
•    All documents marked confidential must be encrypted if they are leaving the organization
•    Communications with the CBER and CDER at the FDA must be encrypted with S/MIME rather than their standard encryption solution. The policy determines which method is used for encryption.

We received dozens and dozens of responses and decided to consolidate them into a paper and host a webcast titled “Optimized Message Processing.”

Check out the paper and the webcast via the links below to see how your peers and possibly even your competitors (company names are not included) are using Sendmail.

We’d love to hear from you about how you are using Sendmail or other email products to solve your messaging challenges.

This podcast is the fourth in a series on how businesses can significantly cut costs by modernizing their messaging infrastructure and stopping unwanted mail. This podcast focuses on filtering techniques that business can take to reduce unwanted email.

Ask the Experts: Messaging Infrastructure Filtering Part 4

This podcast features Sendmail’s executive vice president and chief
operating officer, Glen D. Vondrick, discussing how major enterprises
have been cutting their messaging infrastructure costs during this tough
economy.

Ask the Experts: Messaging Cost-Savings in a Difficult Economy

This podcast is the third in a series on how businesses can significantly cut costs by modernizing their messaging infrastructure and stopping unwanted mail. This podcast discusses functional techniques that companies can take to address “malware”, spam, and other unwanted email.

Ask the Experts: Messaging Infrastructure Functional Techniques Part 3

I want to share with you a paper that Sendmail produced along with Gartner on Modernizing IT Infrastructures.  The following quote from the paper sums up what the Gartner research portion of the paper addresses:

“Most IT portfolios have grown up haphazardly throughout the years, mixing technologies, vendors and architectures that require increasing resources to manage. A modernization program works with the application strategy to drive the IT organization to achieve a desired state. Note that it is not just buying new computers. Modernization is about creating a more-flexible and dynamic IT environment,” (‘Signs Indicate a Train Wreck is Coming, Unless You Modernize IT’, Scott. D. Nelson, Valentin T. Sribar, and Andy Kyte, August 27, 2008.)

The IT messaging environment is no exception. In fact, given the evolution of messaging infrastructures (first spam and viruses, then denial-of-service attacks, address harvesting, outbound policy enforcement, complex routing, etc) it is now a top priority of most enterprise modernization projects.  Is it a top priority of yours?

This is especially true in the financial servers market today. It is impossible for anyone to escape all of the negative news about our country’s financial crisis. It seems like everyday we hear something about banks failing, merging, and being broken apart and sold in pieces.  In fact, since summer of this year there have been six major bank mergers, including such big names as Bear Sterns, Washington Mutual, and Wachovia, not to mention the dozens of regional bank mergers across the county.

The impact these mergers have on the entities involved is staggering on many fronts, including the difficult task of merging the different messaging infrastructures while maintaining great customer service and protecting brand.

In the research note, Gartner outlines the top indicators of a potential IT train wreck in its response to the central question, “What should a company do to avoid this so-called train wreck?” We help translate those indicators into recognizable terms for IT messaging teams by using examples from the experience of its experts.

I think you’ll like it. Check it and let us know what you think.