See You At The Message Systems User Conference!

I’m looking forward to the upcoming Message Systems User Conference next month in San Francisco, not only for what looks like an excellent venue, but for the great set of quality sessions on the agenda.

There’s a number of sessions I’m looking forward to attending, but I’d like to invite you to attend the sessions I’ll be delivering next month (read to the end to save on conference admission):

What the Convergence of Data Security & Privacy Concerns Will Mean to Companies

The barrage of news stories about data breaches and privacy violations is taking a toll on consumer confidence.

What You’ll Learn:

  • Why data security and privacy issues are converging and how an erosion of consumer confidence can jeopardize data availability for communication and commerce.
  • How security and privacy are connected to Message Convergence and why they should now be of concern to all ecosystem players and at all levels, Marketing as well as IT.
  • What principles companies should embrace to address security and privacy in their own environments.
  • How companies can safeguard their customer data and messaging streams.

New Directions in Email Deliverability

Our panel of industry experts will explore the ongoing evolution of deliverability management and new technology advances, such as adaptive delivery, that will make it easier.

What You’ll Learn:

  • How deliverability is a tactic companion to Message Convergence – getting messages delivered, read and acted on.
  • How new advances in technology can improve deliverability management effectiveness and remove the hassles for all stakeholders.

Building Multi-Channel Apps

This session will introduce participants to the whys and wherefores of multi-channel messaging applications ­ how they deliver business value, and how to construct them. You¹ll gain both an understanding of the business strategy behind multi-channel apps, and a nuts-and-bolts working knowledge of the tools and techniques required to design, build and deploy them. Topics will include how to access multiple data sources on the fly and how to make routing determinations. For instance, once you¹ve made a judgment on content, context and preference, how to go about actually getting a message routed to its ultimate destination. We’ll go in depth on the subject of multi-channel message type (MCMT), a proprietary content container format that makes it possible to inject messages into the delivery stream with content alternatives dependent on the preferred message channel.

Target Audience:

Product and program managers, developers, line of business owners.

What you’ll learn:

  • How multi-channel messaging delivers business value across any number of industry verticals.
  • The messaging and data systems/architectures needed to deploy multi-channel messaging.
  • Introduction to MCMT.
  • How to configure Momentum, Mobile Momentum and Message Central for multi-channel apps.
  • Understanding and acting on customer preference data.

Advanced Momentum & Message Scope

This session will extend the sessions on “Introduction to Lua” and “Momentum Essentials and Message Scope” by taking participants through advanced, Lua-based message parsing APIs. Advanced policy scripts for database-driven binding assignment and DKIM signing will be demonstrated. Participants will see practical, but advanced remediation list usage with Message Scope and learn how to create custom remediation actions.

Target Audience: System administrators, operations and support personnel and developers.

What You’ll Learn:

  • Various parsing techniques using Lua API functionality.
  • Write Lua policy scripts that implement database-driven binding assignment and DKIM signing.
  • How to integrate Momentum bounce information with an external database.
  • How to integrate Message Scope with 3rd-party data feeds.
  • How to create custom remediation actions with Message Scope.

It’s going to be a great conference and I look forward to meeting everyone, to make it even more appealing, register now and use discount code VIP2S2 to save $250!

See you there!

14 Email Security Do’s & Don’ts

Note: This article originally appeared at http://www.messagesystems.com/wordpress/?p=84

Introduction

Anyone who follows the email marketing industry news is no doubt aware of the increasing number of well-publicized data breaches that have been occurring at the various major ESPs. In addition to the major ESPs, there are no doubt a number of less-publicized or even non-publicized data breaches occurring all the time at both smaller ESPs and in-house enterprise senders. The days when most of us in the email industry could watch from the sidelines and shake our heads have surely passed. Henceforth we should all operate on the assumption that we’re either now under attack as well, or will be shortly.

Email marketers have two valuable resources that malicious parties want to capture and exploit: information and infrastructure. Attackers want to access the information you hold, including email addresses, personally identifiable information (PII) and affiliation information (which organizations send to which recipients). Using this information the attackers can send spam or phishing messages and (in an unlikely worst-case scenario) even perform identity theft.

In addition to getting to the information you hold, attackers will also try to gain access to your infrastructure. In a recently reported breach at CheetahMail (http://blog.wordtothewise.com/2011/04/another-security-problem/) it was reported that an attacker had gained control of a customer account to send malware (UPDATE: The same thing just ocurred at Bronto: http://blog.bronto.com/2011/05/02/shared-security-responsibility-and-a-compromised-password-incident/). While many reports focus on attacks that result in data leaks, it’s also very common for attackers to access infrastructure to send their own messages from trusted systems, ruining reputation for the operator of the compromised infrastructure.

It’s time for all email marketers, whether sending themselves or through service providers, to make security a fundamental principle in their operations. The Online Trust Alliance (http://otalliance.org) recently published a set of guidelines (https://otalliance.org/resources/securitybydesign.html) that I highly recommend reviewing and following. I’d like to make a few additional recommendations of my own.

People

All the security technologies in the world can often be defeated by a simple phone call or a few dollars. There are multiple cases where attackers have been able to get into a system through social engineering: calling up someone in the target company and presenting themselves as a trusted co-worker and asking for the unsuspecting employee’s login credentials. In other cases a simple offer of cash in exchange for information or access can bypass any number of security measures.

Whether they are acting innocently or maliciously, your own employees (and customers) can easily be your downfall. There are a number of security measures that can help alleviate this:

  1. Educate your employees and users. Make sure they understand what social engineering attacks are and how to identify and prevent them. Teach them to never disclose their usernames and passwords, and enforce a policy of never asking customers for their credentials and make it clear to your customers that you will never do so.
  2. Do your homework. Employ best practices in your HR department. That includes performing background checks on your employees (at least the ones with access to sensitive customer information), including credit checks. Keep in mind that people in positions with access to sensitive data could be susceptible to enticement – this is particularly true if you’ve made it easy for them to act on that temptation.
  3. Apply the ‘need to know’ rule. Consider who really needs to be able to see customer information, and how much needs to be visible. Does someone who manages message templates really need access to your recipient list? Does someone who manages segmentation really need to be able to see both the user and domain portion of an email address? Perhaps they can do their job with access to the domain information only. Do customer service reps really need to be able to see lists of recipients or do they just need to be able to look up a specific recipient to do their job? There will always be people who need to access sensitive information, but not as many as you might initially think, and few need access to absolutely all the information rather than just a subset of it.

Data Storage

There are a number of best practices around securing the data you store, but I want to share a few ideas about what to store, to be used in combination with data security best practices.

  1. Store as little as possible. An attacker cannot steal information that you don’t possess. Do not ask for information you do not need or can’t use. Marketers tend to err on the side of over-collection because it ‘might’ come in handy. (Example: are you asking for a physical address when you do not send anything by regular mail?)
  2. Use encryption where possible. Consider a suppression list to prevent sending to people who have unsubscribed (hopefully you followed step one and purged everything but their address when they unsubscribed); you need to have their address in order to prevent sending to it, but you can store their address as a one-way hash and compare a one-way hash of recipient addresses to identify if a recipient should be suppressed. I’ve worked with senders who encrypt the user portion of every recipient address (mike@messagesystems.com would be stored as 18126e7bd3f84b3f3e4df094def5b7de@messagesystems.com as an example) in the database, with a custom Lua script in the messaging server decrypting the user portion of the address on the fly just before sending. With this approach, they can still do domain reporting and segmentation, while making it much more difficult for attackers to extract useful information.
  3. Purge data as soon as possible. Again, you cannot lose what you do not have. Purge information as soon as feasible, both customer data and the various logs that can contain customer information. If you need a piece of information for a specific mailing, purge the data once the mailing is complete.

Email Infrastructure

While I have no reports to date of email infrastructure as an attack vector there are still some steps you can take to better secure your email infrastructure.

  1. Secure the server. Implement security at the operating system level as well as at the network level. Restrict access to the web UI to internal machines only (use a VPN for external access). Strongly consider using two-factor authentication including password-protected SSH key-based authentication.
  2. Secure your logs. Remember that your logs will often contain address information, so you need to secure your logs with the same vigilance that you secure your database. Ensure that your file system permissions are properly set and that you retain your logs for no longer than necessary.
  3. Customize your logs. If your system supports customizable logging, consider trimming your logs down to the bare minimum data required for your purposes. Instead of storing the recipient email address, store a customer identifier that you can use to lookup the customer address (high-end solutions will let you store just the domain portion of the address so you can still do reporting on domain volumes and deliverability).
  4. Secure against being an open relay. Grant permission to inject mail on a per-IP basis if possible, use TLS and authentication if you need to allow relaying to external hosts.
  5. Scan your outbound mail streams. An effective way to mitigate infrastructure attacks is to filter all traffic as it leaves the server to prevent sending mail that contains viruses, spam or malware. The incident at CheetahMail I mentioned at the start of this entry could have been prevented with outbound traffic filtering. Keep in mind I’m speaking about AV/AS filtering on a per-message basis. It’s not enough to send a test message to a preview tool if you’re trying to protect your infrastructure; you need a messaging server that can filter traffic on egress.
  6. Implement Feedback Loops. While this may not seem like a security tool, I’ve worked with senders who were able to use a spike in incoming FBL messages to identify an unusual sending pattern coming from their servers, leading them in turn to identify that their network had been compromised and a malicious attacker was using their system to send mail.
  7. Implement authentication tools such as DK/DKIM/SPF/SenderID. Again, this does not directly secure your data, but if a list is compromised it will be harder for a malicious party to deliver mail from their own servers and make it appear to come from you (especially when making phishing attempts with your data).
  8. Monitor Block Activity. As with spam complaints, a sudden burst in rolling blocks could be a red flag that an infrastructure beach has occurred. Set-up alerting system for blocks and automated suspension processes to catch and shut down malicious mail streams before serious damage is done. The good news, if you’re running Momentum, is that our Adaptive Delivery product does this for you automatically.

Conclusion

The latest security breaches in the email marketing industry have re-enforced that an attack is a matter of when, not if, and senders need to plan accordingly. The recommendations of the OTA, combined with the recommendations above (and constant vigilance) should provide a good start at avoiding (and minimizing the impact of) a malicious attack.

Be Aware: Phishing Attack Targeting ESPs and Large Email Senders

This just in from Return Path:

Over the course of the past five weeks, spam campaigns have been aimed at the staff members of over 100 ESPs and gambling sites. These targets have received emails typically with content that mentions the staffer by name, and purports to be from a couple, presumably friends or co-workers.

The phish message has been sent numerous times, over several different systems, including using the facility of some ESPs, using online greeting card sites, and by way of a botnet. Sources confirm the list of addresses is very small (less than 3,000 addresses) and aimed 100% at staff responsible for email operations.

The message links to a site that contains a particularly nasty payload. I received one myself and deleted it as I thought it was harmless spam so the attack is going after email infrastructure providers in addition to ESPs.

Click through to the Return Path article for security advice in regards to this attack.