Enterprise DMARC: Selling the Project

More people involved means more politics

In an enterprise DMARC deployment there are a lot more people involved. Different departments and department heads, which means internal politics. It's entirely possible that portions of your network may have been delegated to other DNS systems so that they could be managed directly by different departments for the sake of efficiency. You could have delegated all or part of a subdomain to a web application firewall (WAF) provider like Cloudflare. There's more moving parts here behind each email system and that has to be taken into account.

Differences in priorities will color a great deal of the perspective on DMARC within an organization. A lot of experienced people will tell you that security comes last in many organizations. In some cases this is by necessity rather than negligence, as there's often only so much budget to go around and a lot of competition to capture market share. To get DMARC setup, just getting the project approved in the first place will take some doing. Here's a few things to know that will help.

Government Requirements for Legal

The Department of Homeland Security (DHS) 18-01 Binding Operational Directive required all federal agencies to have a DMARC policy of p=reject by October 16, 2018. 74% of agencies did it in time according to a report from Agari. Similar requirements happened in the UK in 2016. The Dutch government went so far as to add DMARC to their email standards checklist that's part of the "Comply or Explain" list for business operations in the country. Businesses can depart from the compliance requirements, but they must provide a written explanation to justify the course of action. More an more it's becoming a baseline expectation of doing business, particularly with government agencies. Adoption is being pushed heavily across the US, EU, Japan and more.

It's probably only a matter of time before DMARC is folded into security standards like SOC2 Type II and ISO 27001.

Business Email Compromise (BEC) for Executives

The executive team will probably respond to BEC, also known as Spear Phishing or Whale Phishing. BEC scams target financial departments at companies by having those companies issue checks and vendor payment through social engineering. These scams work because the criminals are able to successfully impersonate company executives. Often times an entire fake email chain will be created that appears to be a multi-day conversation between an executive and a fictional vendor wondering why they haven't been paid. The executive will then forward the entire email chain to the finance department to get these people paid promptly. It's believable because, via email, these executives can be impersonated if the protections aren't in place.

You read something like that and your first thought it, "that could never happen" but these scams are responsible for $12.5 billion in losses from 2013-2018 according to the Global Cyber Alliance. How accessible is your CEO for a verification phone call if you were to receive an email like that, particularly from their company email address? It's easy to do without DMARC in place. Even with DMARC in place it can and does still happen, but perpetrators have to convince you they are the same executive but on a personal email account with Gmail or some other provider. It's much easier to spot. Many email and service providers like Greathorn and Google provide tools to help warn people about them...but those tools can't do anything about messages that come from the corporate email domain.

BIMI is a Carrot for the Marketing Department

Is it probably necessary at a large company to get the marketing department on board? Yes. Because marketing might fight you on setting it up. I've spoken about DMARC during an email marketing conference and had the conversations first hand. This will sound harsh, but your marketing department probably does not care at all about email security. What they care about are delivery, inbox placement, open rates and clicks. A DMARC project will likely scare the marketing folks more than anything as they wonder and speculate about a potential negative impact to these metrics. DMARC won't hurt these at all. If anything, it helps protect the brand by making it more difficult to impersonate.

And many will go as far as fighting against the DMARC deployment because of it. After all, what's in it for them? Well, now there's something for them too.

Once DMARC has been rolled out successfully you're eligible to setup Brand Indicators for Message Identification (BIMI), which will allow a trademarked logo to appear next to your emails right in the customer inbox. So far, it's supported by Gmail, Yahoo, AOL and Fastmail.

As a person try to improve security for your company and your users, you may be wondering if this has any positive impact on security by providing some type of reassuring trust indicator next to the email. This, unfortunately is a resounding, "No." Users do not respond to trust indicators because there are so many messages and websites they come across that do not have them. Because of that, users simply ignore missing indicators.

As a parallel you may remember Extended Validation Certificates security certificates. Companies paid a lot of money to go through a validation process that would turn the address bar in the browser green if they'd been validated. These were completely ineffective. The same certificate authorities who validated EV certificates are the Mark Verifying Authorities (MVA) doing the validation for BIMI to get you a Verified Mark Certificate (VMC). A 2018 study presented at M3AAWG also revealed no impact (positive or negative), aside from more email senders contacting email providers asking how they could get the indicators too.

BIMI is the Make My Logo Bigger Cream of email. It's a dangling carrot, but if it gets marketing on board with the project and it does no harm it is probably worth it for the overall security improvement. You still have to fully deploy DMARC first.

Reigning in Shadow IT for Security

One of the biggest struggles that IT and Security teams deal with at large companies is Shadow IT. Shadow IT happens when employees start using devices, tools and services that have not been approved by the company to meet with various internal standards and compliance.

Now, it's important to remember that Shadow IT rarely comes from malicious intent. The cause is traditionally an expected very high barrier to approval, numerous hoops to jump through or long timelines from IT itself which encourage people to go around IT to get their jobs done. Shadow IT is often a symptom of a process problem.

All that said, DMARC reports provide real insight on the scope of this problem within your organization. If you start collecting reports with dozens of legitimate 3rd party services that haven't been approved...you have a problem.

Does private data exist within these tools? Employee data? Customer data? Is PII collected? How are logins managed? Is access being removed during employee turnover? Are their legal or audit implications?

By knowing the tools exist, you gain the ability to get their usage documented, approved, secured properly and rolled into more polished company process. If you're unable to find out who's responsible you can always use the time honored IT sleuthing process of unplugging it until somebody complains. Enforcing your DMARC policy will have the same effect.

This article was originally published on as part of a 3 part DMARC Guide at Brightball.