What are you doing to make the integrity of your corporate email/messaging an integral part of your information security policy? If you don’t have a definitive answer for this question, then read on. I’ve got some great advice from experts on the topic that you can take action on today to protect your company’s brand.
I recently interviewed Alec Peterson, CTO of Message Systems, and Sam Masiello, head of application security at Groupon. Both men have been in the enterprise email and messaging space for many years, and they provide their expertise through a group called DMARC.org. DMARC stands for Domain-based Message Authentication, Reporting and Conformance. It’s a technical specification to help reduce the potential for email-based abuse, such as when someone sends a phishing email that appears to come from a legitimate company, but it’s really from a malicious source.
Let’s say that you receive an email that appears to come from PayPal, and the message contains a link to go to PayPal’s website. How can you be sure this is a legitimate message with a safe link, and not a spoofed message designed to steal your PayPal account credentials? Therein lies the problem. A few years ago, PayPal topped the list of legitimate brands whose name and reputation was usurped by criminals for use in phishing attacks.
When we think of the victims in phishing attacks, we tend to think of the recipients of messages who fell for the ruse and gave up sensitive information or downloaded malicious software. But there are other victims in these attacks, and they are the companies whose brands are abused in the attacks; in my example, it’s PayPal. In fact, at one time a few years ago, PayPal’s brand was so frequently associated with phishing attacks that many people simply ignored legitimate mail coming from the company. You can see that this kind of behavior can be very detrimental to a corporate brand – perhaps even your company’s brand – and something needs to be done to preserve the reputation of the company sending out valid email messages to its customers.
Now that you have some context of the problem, we’ll dive into my interview with Alec and Sam.
Linda: What is the issue about integrity of email?
Alec Peterson: The utility of digital messaging is only as useful as how much people can trust it. With the number of phishing attacks that have been going on for a while now, that trust is at risk. When you get a message from, say, RegionalBank.com, the nature of the original email standards was that anyone could say they were sending mail from RegionalBank.com. If somebody was trying to get you to provide confidential information by replying to or clicking on something in the email, it was very easy to create a false sense of security. Someone who knows you have a relationship with that bank could tell you that you need to reset your password, and then send you a link to a fraudulent website to capture your password or your account information or other sensitive information.
The fundamental challenge that the messaging industry wants to solve is to authenticate messages in some way. We want to give the recipient of the digital message the confidence to say, “This message purports to be from RegionalBank.com, and because of the fact that it is authenticated, I can have that confidence that it is legitimate.”
Linda: What standards were developed to authenticate messages and ensure the integrity of legitimate email?
Sam Masiello: There are several authentication mechanisms. When you look at email authentication, there are two standards that exist in that space. One is SPF which stands for Sender Policy Framework. (See www.openspf.org/Project_Overview.) SPF is basically an IP-based path-based authentication mechanism. So RegionalBank.com can say to receivers such as Comcast, Gmail and Yahoo!, “These are the IP addresses or the third parties that are allowed to send mail on my behalf and these are the IP addresses that they are sending from. If you see something that is not coming from any of these IP addresses, then it doesn’t pass SPF and the mail can be rejected.” That way, the spoofed email never gets past the ISPs and to the intended recipients.
The second method is called DKIM which stands for DomainKeys Identified Mail. (See www.dkim.org/.) This is a signature-based authentication. When a message is sent out, certain parts of that message are signed so that when the ISP receives it, they can validate to ensure that the pieces of the message that were signed did not change during the transmission of that message. This means that the person who receives the message can be sure that the content of the email when it is received is exactly the same as when it was sent.
Between these two standards, you can tell a pretty strong story for email authentication. Not only is the message being sent from a legitimate IP address that is allowed to send a message on my behalf, but you also can be sure that the message is the same when it is received as when it was sent. So these are the two pieces that make up the email authentication space.
Linda: With these two standards in place, what precipitated the additional need for the DMARC standard? In other words, why aren’t SPF and DKIM enough to ensure authenticated messages?
Sam Masiello: Even though these email standards were developed to give users confidence in the messages they receive, there was still a problem that existed from the ISPs’ perspective. Take Gmail, for example. Gmail didn’t necessarily know whether RegionalBank.com was using this email authentication technology for all of their email. So the ISPs were reluctant to take any sort of hard stance on rejecting email that looked like it was coming from them but that wasn’t authenticated because they didn’t know whether the sender was authenticating all of their mail. What the ISP was looking for was some way for the brand to be able to say, “Yes, I am authenticating all of my mail that you, the ISP, receive from me, and if the mail doesn’t have the authentication stamp, it isn’t from me.”
That was a large part of the reason why DMARC was developed to begin with—to give brands like RegionalBank.com the ability to set that policy to say, “Yes ISP, all of my email is authenticating properly and if you see something that appears to be from my domain that is not authenticated, then it is not from me. I am telling you that I want you to either quarantine or reject that mail going forward.” This type of policy gives ISPs a definitive mechanism to always reject spoofed mail.
Linda: What else does the DMARC standard provide?
Sam Masiello: DMARC was developed for two reasons. One was to initiate that policy mechanism for rejecting email messages that don’t adhere to SPF and DKIM standards. The other piece that DMARC provides – and this is very important from the perspective of an email sender like RegionalBank.com – is that the sender can receive visibility through DMARC reporting as to everyone who is sending mail on their behalf. That means not only their corporate mail but also their mail that may be sent through an email service provider—possibly another provider that sends out marketing or customer service related messages, or anyone who is allowed to send mail on behalf of that domain.
DMARC provides reporting back to that brand owner so they can see everything that is legitimately being sent on their behalf, such as all of their legitimate corporate mail and affiliate mail. More importantly, they also can see anybody who is potentially out there sending out malicious email on their behalf, so they can see where a spoofed email is coming from and where the phish email is coming from. They get visibility into not only where it’s coming from but what the message looks like as well.
DMARC is created primarily to provide those two pieces of functionality into the email stream. One is a statement to allow the brand owner to tell the ISP to start blocking things that aren’t legitimately coming from them. The other function is for the brand owner to receive that visibility that is reported back to them so they can see where all of their mail is coming from—both legitimate email that they are sending and the bad stuff that the bad guys are sending.
Linda: Where is this reporting information coming from?
Alec Peterson: It’s important to understand that DMARC is a standard; it’s not a centralized service or anything like that. It’s entirely distributed. Don’t think of it as some sort of centralized cloud service that collects everything. Think of it as a policy announcement from a brand that any ISP can look at. Then any ISP can report back to any sender who is providing DMARC. It’s really this message mesh across the Internet as opposed to anything being collected and centralized.
Linda: So when Sam was talking about getting a report, it’s really not one report but a series of reports that come from different ISPs.
Alec Peterson: Yes, that’s how it works.
There’s much more to this interview, folks. Join me in a few days when we post the second half of the discussion where Alec and Sam talk about how companies use DMARC, what benefits they get from it, and what you can do to deploy this standard within your own organization.
- About Corero
- Investor Relations
- News Room
- Executive Management Team
- Corero Offices
- Contact Us