BITS: Improving E-mail Authentication
Banking Group Issues Tips for Foiling Phishing Attacks
In its new report on using e-mail authentication to fight phishing attacks, BITS offers a list of best practices and recommendations, including expanded use of the DMARC security protocol.
BITS, the technology policy division of The Financial Services Roundtable, believes that the Domain-based Message Authentication, Reporting and Conformance protocol plays a key role in mitigating phishing schemes.
DMARC standardizes how e-mail receivers perform e-mail authentication by providing a uniform reporting mechanism that's built on reputation.
"DMARC is pretty helpful in a couple of different areas," says Andrew Kennedy, senior program manager for BITS' security initiatives, in an interview with Information Security Media Group [transcript below].
Kennedy sees DMARC as an overlay of the Sender Policy Framework [SPF] and DomainKeys Identified Mail [DKIM] protocols, which aid in e-mail authentication.
"If there was an authentication failure for one of those protocols, it leaves you in the lurch if you don't have a policy in place to deal with that, and DMARC helps close the gap there," he says.
Also in the interview, John Carlson, executive vice president of security programs at BITS, stresses that an essential component when fighting phishing is for banking institutions and their business partners and customers to follow similar authentication strategies. "It requires extensive collaboration from many different groups within the company and outside in order to implement these controls," he says.
During this interview, Carlson and Kennedy discuss:
- All of the e-mail protocols that address phishing attacks and how the protocols work in tandem;
- Why spoofed websites are increasingly concerning; and
- Steps banking institutions are taking to get business-partner buy-in for the DMARC initiative.
At BITS, Carlson works with members to strengthen the security and resiliency of financial services through best practices and strategies for secure IT systems infrastructures, products and services. He also collaborates with the Financial Services Sector Coordinating Council for Critical Infrastructure Protection and Homeland Security, or FS-SCC, and co-chairs its Threat and Vulnerability Assessment Committee. He re-joined BITS in December 2011 after serving as a managing director at Morgan Stanley.
Kennedy, now the program lead for BITS' security initiatives, previously served as project manager for the BITS Vendor Management Program. He interned at BITS in 2006 and worked as an IT professional and security consultant in the biotech and software industry in California.
E-Mail Authentication Guidelines
TRACY KITTEN: Before we get into some of the details, could you talk a little bit about what prompted BITS to update the guidelines that it first issued about e-mail authentication back in 2009?
JOHN CARLSON: We'd be happy to talk about the BITS e-mail authentication policy and deployment strategy for financial institution firms. The reason why we had issued this paper was to help our financial institutions to better leverage several protocols and tools to detect and reduce the number of spoofed e-mail messages that reach consumers and business partners. A key component here is that e-mail is a critical communications channel for business today, and many of our institutions are dealing with spoofed e-mail messages that oftentimes are the vector for transporting malicious software or for tricking users into thinking it's coming from a legitimate user. We decided that it was important to issue this paper to help our financial institution member companies better leverage these protocols and gain some of the significant benefits from use of these protocols in terms of reducing fraudulent e-mail to customers and prospective customers, to reduce phishing attacks against high-value or trusted domains, to increase customer and partner confidence and trust in the authenticity of the sender's e-mail, and, very importantly, to enhance the brands of institutions in terms of the exposure of customers to phishing attacks that could lead to fraud or malware infection on their computers.
KITTEN: Have phishing-attack upticks been significant enough to warrant this update?
ANDREW KENNEDY: While phishing attacks continue to rise, this update was not really driven by the threat in that space. Some of the technology changes in this area have been the bigger drivers, as well as the publication of Domain-based Message Authentication, Reporting and Conformance, or what's better known as the DMARC protocol that was published back in January of 2012. We just passed the one-year anniversary of the publication of that specification. Also, as an industry, we're better understanding the model for success, including from a statistical side what we're seeing in terms of protecting our customers, protecting our brands from erosion from these spoofing and phishing attacks, as well as helping our marketing and communication teams get a lift on the delivery side.
CARLSON: Let me add to that. One of the reasons why we published the paper was to help our member institutions implement these e-mail security protocols and to deal with the many different parts of the organizations, both internally and externally, including Internet service providers and e-mail service providers, because it requires extensive collaboration from many different groups within the company and outside in order to implement these controls. [With] the uptick in the phishing attacks, which has been a problem for not only our industry but multiple industries, I think this tool will be a very helpful resource to guide institutions in how to deploy these and some considerations they will invariably need to take into account as they deploy them.
KITTEN: What about spear-phishing? Has this noted exceptional increases here as well?
KENNEDY: Spear-phishing continues to be an issue. Spear-phishing really attacks a specific individual. It's going after someone in particular. These protocols address the phishing issue from a higher level, [also] looking at the aggregate issue, focused more on protecting consumers as a very large group. It does help reduce the surface area of attacks in terms of some spear-phishing attempts, but it really looks at the broader spoofing issue in terms of trying to get customers to click on malicious links or open malicious attachments.
KITTEN: Would you say that some of these phishing attacks are actually getting around some of the outdated protocols that are existing?
KENNEDY: ... I think you're referring to the Sender Policy Framework or DomainKeys Identified Mail. Those are protocols that are approaching the 10-year mark for their specifications being published. They address a specific issue. SPF focuses on white-listing IP addresses for sending mail servers, and it does that very well. DKIM is all about applying signatures to both the header and the body of an e-mail. Again, those are working pretty well. The real thing here is that DMARC mixed those two protocols together, and if there's authentication failure for one of those protocols, it helps the receiver understand what to do. In some cases, that means delivering the e-mail, and in other cases it may mean not delivering the e-mail. It gives some options to the sender in terms of how they want their policies to be enacted. I wouldn't really characterize these protocols as outdated. I would actually characterize them as working together and DMARC helping them work better and give more policy options for both the sender and the receiver.
CARLSON: ... We've always viewed that implementation of the standards - SPF, DKIM as well as DMARC - are really meant to provide that foundation for building more complete end-to-end e-mail security solutions. They're complementary with each other.
KITTEN: The 2009 document does offer recommendations for more up-to-date e-mail sender authentication protocols, which you noted. What were some of those protocols, and how would you say that they could they be improved upon?
KENNEDY: As I mentioned, the Sender Policy Framework is a white list for sending mail servers. The DomainKeys Identified Mail finds the e-mail headers in the body, which can be automatically checked against a public key published in the domain name system, or DNS. DMARC is an overlay of SPF and DKIM and helps align these protocols together. DMARC is pretty helpful in a couple of different areas. It helps assert the sender policy to the receiver.
As I mentioned, if there was an authentication failure for one of those protocols, it leaves you in the lurch if you don't have a policy in place to deal with that, and DMARC helps close the gap there. DMARC also helps with the wild carding and the sub-domain policies. You can deploy a policy for all your sub-domains with just one line in the DNS. It's very good at the faster deployment and closing a lot of surface area in terms of where mail can be spoofed from. It helps with a nonexistent sub-domain. Senders can tell receivers that these sub-domains don't exist and they shouldn't be accepting any e-mail from them. Or, if these domains exist, they should or shouldn't be seen as sending domains.
It also helps with the rolling out of the technology. DMARC gives the option to turn on the checking on the receiver side for some percentage of the e-mail that they're receiving. That way, when they're reporting back what they're doing with that e-mail, it could be done on a small percentage of e-mails. The sender can learn if there are issues along the way before it turns it on for all e-mail. It makes it much easier to deploy with the assurance that it's working properly. It also falls to the solution of SPF and DKIM being seen as different technologies and different protocols; it helps them work together in parallel. Then, it also helps ask the receiver to act upon e-mail in different ways, in terms of: Has it been authenticated or not? Where does that e-mail end up going? Does it go in the inbox? Does it go in the spam folder? Does it not get delivered at all?
Another benefit is on the reporting side, where getting this information back from the receiver to the sender, the sender can then see what's happening in terms of the false positive space, whether the authentication is working properly. It also helps reduce the success of phishes by having a policy in place. It works at Internet scale, which is very key, [meaning] no more one-off relationships with specific ISPs. It really helps deploy these technologies across the board to those who are also deploying it on their end.
Embracing the DMARC Initiative
KITTEN: What recommendations is BITS offering to member institutions about how they should embrace the DMARC initiative?
CARLSON: Our recommendations are based upon what our members collectively put forth as best practices. Through our members, we have enthusiastically embraced DMARC from the very beginning, as we mentioned earlier, as a way to tie together the SPF and the DKIM protocols in a complimentary fashion. Our members are enthusiastic supporters of DMARC, and we encourage them to adopt it.
KITTEN: The document that's just been issued also covers business and process considerations to leverage e-mail protocols and tools, and you've touched on some of that and how everything fits together. Are there any other processes that we haven't talked about that are included here in this document?
KENNEDY: The document is pretty comprehensive and we'd certainly encourage those listening to download the document and look through it themselves. What's very clear at this point is that there's a number of different stakeholders, both externally and internally to a company, when it comes to e-mail. When a security team that may be tasked with deploying this technology looks at the issue, they realize that they have to go to their partners on their DNS teams; their IT risk and compliance teams; the security operations teams; the marketing department who are senders of a lot of these e-mails; the consumer service team, which is perhaps receiving information from customers about e-mails that they're receiving; and the vendor management component, which are working closely with the third parties who are often tasked with sending some of these e-mail campaigns. There are a lot of different working parts that need to be brought together in alignment to help deploy these protocols.
On the policy side, the marketing and business and transactional e-mails, they need to be segregated out. Domains and sub-domains need to have policies applied to them, and how that works within the company needs to be understood. There needs to be consistency in terms of the "from" field within an e-mail, and that will help with the identity alignment issue that DMARC helps to solve. Then, [with] the nuts-and-bolts of doing domain inventory, know what domains you have control over, make sure those are covered by your e-mail authentication policies and work with your authorized third-party senders because they also need to be deploying these technologies or else their e-mail may not be delivered appropriately.
KITTEN: What about partnership services such as those facilitated through joint efforts coordinated by BITS and the Financial Services Information Sharing and Analysis Center?
KENNEDY: BITS and the FS-ISAC have been working with two trusted e-mail registry partners. Those are Agari and Return Path. They provide a great service for our members to help get the threat intelligence that they need about what's going on in terms of e-mails that are purported to be sent from our member institutions. The service providers help take in the reports from the receiver side and help put it into charts and graphs that are easily consumable by security professionals. They also get other information outside of the DMARC protocol that helps as an alternate mechanism for getting some of this information from some of the receivers who have not yet deployed DMARC. It's a great service to help understand what's happening in the e-mail space because, while you may be sending e-mails, you don't always know who's spoofing you unless you're getting those reports back. We believe a trusted e-mail registry service is really the only way of getting that sort of information.
KITTEN: Before we close, what final thoughts would you like to leave our audience with and what would you say should be the top e-mail authentication concerns as we move forward into 2013?
KENNEDY: We continue to work on the deployment side, but in terms of the technology change here, we're seeing trends in mobile where there's just a great uptick in growth there, especially on the consumer side. Mobile platforms have certain limits to them in terms of processing power, screen size and that sort of thing. A lot of decisions have been made that remove some of the things that you have access to in a typical mail client in terms of being able to see the header of an e-mail and that sort of thing. We need to start to think about other ways of getting information that would help the consumer make the right decision in terms of where this e-mail came from and whether it's an authorized e-mail or not. In terms of adding the trusted mark to the mobile platforms, in terms of educating consumers of what the trusted mark stands for and what it means, there's definitely a campaign that needs to happen of getting consumers to understand what protections they have and when those protections aren't there.