alex_aldo - Fotolia

News Stay informed about the latest enterprise technology news and product updates.

Google to adopt strictest DMARC policy to fight spam, phishing

News roundup: Google to implement strictest DMARC policy in anti-phishing campaign. Plus: CISA is coming, the health care industry is lagging and SHA-1 is failing.

Google announced this week that it is transitioning to the strictest setting of the anti-phishing and spam tool...

DMARC (Domain-based Message Authentication, Reporting, and Conformance), stating the transition to a DMARC policy of "reject" would occur in June 2016.

DMARC's anti-phishing and anti-spam functions work by authenticating messages with their sources, so that email with spoofed headers would be rejected. DMARC policy settings range from "none", used as an initial gateway into the protocol, meaning that no actions are taken regarding delivery of the messages flagged, though they may be reported. Under the intermediate "quarantine" policy, the mail receiver reports messages that fail to authenticate as suspicious and places them in a spam folder or flags them for further examination. Google is transitioning to the strictest setting, "p=reject", which means the recipient rejects any messages that fail to authenticate.

Yahoo and AOL made the move to the strictest DMARC policy setting in April 2014, and earlier this month Yahoo announced they would transition its Rocketmail and Ymail services to that policy starting November 2.

When Yahoo made the transition to the strict policy for the bulk of its mail customers last year, Jeff Bonforte, SVP of Communications Products for Yahoo, praised the anti-phishing effect that implementing DMARC produced when he wrote in a blog post last year that, "overnight, the bad guys who have used email spoofing to forge emails and launch phishing attempts pretending to come from a Yahoo Mail account were nearly stopped in their tracks."

When AOL followed Yahoo's move to the stricter policy last year, there were some glitches in the transition. Some legitimate senders, such as email distribution list services and websites that forward messages on behalf of their users, were having messages flagged and rejected, but the relatively simple fixes mostly involved making sure that messages were not sent with forged headers indicating inaccurate message sourcing.

DMARC depends on two older tools for authenticating messages as having originated from the domain in the From: header of the message: the DomainKeys Identified Mail (DKIM), which makes it possible to cryptographically authenticate that a message originated from the From: address in the message header; and the Sender Policy Framework (SPF), which gives large mailbox providers a way for recipients to determine whether or not a host that has forwarded mail is authorized to do so.

Another email security protocol in play

Meanwhile, in other email protocol news, the German Federal Office for Information Security reportedly now wants German email providers to support a new Internet standard which adds "opportunistic" TLS security to SMTP, meaning servers that support TLS for SMTP will be able to encrypt message streams, while not requiring massive upgrade of all email servers. The result is that email streams can be encrypted when server and client nodes both support DANE, but will fallback to plaintext in other cases.

The protocol, "SMTP Security via Opportunistic DNS-Based Authentication of Named Entities (DANE) Transport Layer Security (TLS)" allows SMTP message transfer agents (MTAs) to negotiate TLS encryption of traffic between servers that have published authentication and encryption keys via DNSSEC. SMTP does not have a requirement to use encryption, which means that email is often transmitted in plaintext; the new protocol gives SMTP agents a mechanism by which they can negotiate encryption for mail transfers -- if both agents support it. While it does not make TLS encryption mandatory, it does allow an easier upgrade path for the Internet to support email transfer encryption without a global upgrade.

The end result is that man-in-the-middle attacks against mail servers can be thwarted, and message transfers can be encrypted between SMTP servers that support the protocol.

In other news:

  • After many delays, the Senate voted (83-14) to begin debate on amendments to the Cybersecurity Information Sharing Act (CISA) this week, with a vote on the bill scheduled for next Tuesday afternoon. CISA has broad bipartisan support and is expected to pass next week. However, hurdles remain as there is wide opposition from grassroots organizations as well as software and other technology companies. The bill would also have to be reconciled with a version that was approved by the House earlier this year.
  • This week Cigital Inc. released data from latest release of the sixth version of the Building Security In Maturity Model (BSIMM6) showing that the health care industry is lagging on software security. The healthcare industry data, added to the model in the wake of the Anthem and UCLA Health data breaches, "confirm underlying issues in healthcare software security practices," according to Cigital. Dr. Gary McGraw, CTO of Cigital, stated that "the addition of healthcare in BSIMM6 enriches the model and shows growing awareness of all verticals toward measuring their software security initiative. The healthcare data show that the industry has plenty to learn from other industries when it comes to software security. Fortunately, the BSIMM community is set up to facilitate and accelerate that learning."
  • In the wake of publication earlier this month of a paper showing that a practical defeat of SHA-1 is within the financial reach of criminal enterprises, and that signature forgeries could be seen in the wild soon unless SHA-1 is deprecated, Mozilla is considering accelerating its schedule for rejecting SHA-1 SSL certificates as "untrusted connections", moving the deadline for servers to update their certificates from January 1, 2017, to July 1, 2016. The paper, Freestart collision for full SHA-1, showed that the cost of defeating SHA-1 has dropped in part due to the efficiency of using graphics cards, and they "project that a real SHA-1 collision will take between 49 and 78 days on a 512 GPU cluster. Renting the equivalent GPU time on EC2 will cost between 75K US$ and 120K US$ and will plausibly take at most a few months." According to Netcraft's October survey, millions of businesses are still using SHA-1. SHA-1, which was declared "dead" in 2005 by Bruce Schneier, but it is still being used by millions of businesses, and CAs are even still issuing SHA-1 certificates, according to Netcraft's October survey report.

Next Steps

Learn what works best for anti-phishing efforts

Read more about a recent Gmail phishing attack

Discover some cloud anti-phishing strategies


Dig Deeper on Email and Messaging Threats-Information Security Threats