ISMS Essentials: Get the message with DMARC
What is DMARC and why should you adopt it in your ISMS?
DMARC is an email message validation system that helps stop phishing fraud that is fast gaining traction around the world. We will step through what it is, how to apply it and the threats it will help you avoid.
DMARC – Domain-based Message Authentication, Reporting & Conformance
DMARC is a protocol that enables domains to trust each other by providing identity and proof of who they really are. Your “domain” is essentially the totality of IT within your organisation that forms your network and connects to the Internet.
The domain includes the organisation’s identity that is presented to the outside world such as website addresses. DMARC is concerned with inbound and outbound email traffic and the technology that sits behind it such as the Domain Name System (DNS) and email infrastructure like Microsoft Exchange Server.
This video briefing gives an idea as to the likelihood of attacks that DMARC can help avoid:
Who uses DMARC?
DMARC enables authentication between different domains as part of the exchange and transfer of email messages into and out of an organisation. It is supported by the likes of Google, Paypal and even LinkedIn, organisations who rely on the internet to be trusted and secure without security getting in the way of people getting work done.
In the UK, DMARC has been adopted by the Department for Work and Pensions (DWP) and HM revenue and Customs (HMRC) as their domains were a favourite for spoofing activity, with attackers attempting to phish details from unsuspecting members of the public. Attackers posed as these legitimate organisations claiming that there was a problem with benefit payments, an extra payment was due or a tax rebate awaited the submission of the recipient’s sensitive information or bank details.
As adoption grows further, it is inevitable that DMARC will become a “cyber essential” and a sign of best practice within the UK government and commercial sectors and around the rest of the world. It is definitely a cost effective control to consider as you design, build and maintain you ISMS.
An essential ISMS component: Overview of how DMARC works
Organisations have a Domain Name System (DNS) that is handled by a DNS server and produces DNS records. DNS records include information about how messages are handled and can include information about any DMARC policy that has been set.
The objective of DMARC is to validate the email sender. When an email is sent, the recipient email system is able to call back to the sender to automatically check and authenticate that they are who they claim to be. It is able to do this because a Sender Policy Framework (SPF) tells other domains where email messages from the sender organisation can originate from by way of IP address inclusion. The SPF is just a different type of DNS record.
The SPF works in combination with Domain Keys Identification Mail (DKIM), another common IT standard that DMARC uses. Think of DKIM as a signature that goes with every message and means that the recipient system is able to check that the signature [data] is as it should be and has not been forged or interfered with.
If the email is correct (i.e. it conforms and fully authenticates) then it arrives in the inbox of the intended recipient. If the email is incorrect (i.e. authentication fails DKIM or SPF) then, depending on the recipient policy that has been set, the message is rejected (junked as spam) or quarantined for review.
DMARC and ISMS benefits
The primary benefit of DMARC is as a technical control to prevent somebody from forging and spoofing your organisation’s identity, where a threat actor masquerades as your organisation and abuses the trust, authority and any implied consent that your brand and mission carries.
You might already have email filtering and content checking capabilities but these tend to protect you within the network or at the network boundary. Those people out on the internet who receive emails that come from you, or appear to come from you, are not in scope. DMARC is not designed to replace these gateway email solutions but will enhance them by adding message authentication to your security defences.
Imagine that your organisation is a bank and an attacker has created a replica or illusion of your wider email and web site identity. This makes phishing attacks far more likely to be successful because they will look legitimate to the message reader who will be more likely to surrender personal details and credentials.
Other benefits of DMARC include a reduction in spam emails generally, and a view as to where emails that come from your organisation are actually sent from – hence improved visibility of your inbound and outbound email use.
Where DMARC will not help your ISMS
While direct domain spoofing can be prevented by DMARC, sometime attackers will create fake domains that look very similar to yours but are not exactly the same:
e.g. “email@example.com” is not the same as…
Unless the reader is particularly sharp-eyed they are unlikely to spot there is something wrong.
Similarly, if yours is a “.com” domain and the attacker creates a “.net” or other similar looking address, DMARC will not stop or prevent this from happening.
Undertaking DMARC configuration
Configuration will be carried out by your network/email admin team, and often in conjunction with your ISP if they have a role in maintaining your DNS records and network domain settings. There should not be a financial cost implication in DMARC adoption but you should consider the time of the administrator, the time taken to receive and understand DMARC reports, as well as the involvement of any IT change control processes to formally accept the change.
First you need to enable “monitoring mode” in the DNS record and your domain admin will do this by adding TXT files that provide the relevant instruction by way of “tags”. Only 2 tag values are required to get started, the rest are optional. This table is a compilation of tags from common sources across the Internet:
- “v” says that this is DMARC relevant protocol
- “p” states that no policy has been set (more options in a moment)
- “rua” is telling the wider world the address to send DMARC reports back to
With the policy value set to “none” it means that there will be no impact or change to the way that emails flow. What we will start to get (it may take a day or 2) are DMARC reports back to the address that has been set up. You should be able to receive statistical reports even when SPF and DKIM are not yet in use on your domain.
When you eventually adopt SPF and DKIM, these reports will become enriched with information including the sources and identities of other domains and the messages that pass or fail authentication.
DMARC Reports: Don’t be surprised if you send emails from strange places
DMARC reports can give you visibility of any other domains that send emails on your behalf including those that are legitimate. This might sound odd but if you outsource marketing, telesales, public engagement or business functions like HR, they may well need to legitimately send emails that are “from” your organisation but not necessarily posted by your organisation’s core IT domain.
The team responsible for domain admin needs to add these acceptable domains to your records. If you don’t, then you risk messages being quarantined or rejected as spam when the policy value is modified to something other than “none”.
Don’t forget that your organisation might also use Gmail, Office 365 or other cloud hosted services to send email, they too can be added into your DMARC approach and you will see these sources within received DMARC reports.
Most third-party services that support DMARC provide guidance on how to add their domains to your SPF records and DMARC configuration. This is a link to Google, a strong advocate of the DMARC standard, which is vitally important if your organisation uses Gmail.
You can even add IP addresses of any applications that might also be used to send email. This too may sound a little strange but there are plenty of operational information applications that have a messaging interface and could send emails (perhaps as notifications to application users).
Ultimately all that happens within such apps and databases, is that whilst messages are constructed within a bespoke interface, the messages are sent via your standard server and gateways just like any other email, perhaps with attached records and metadata regarding content, any classification marking and structure.
DMARC Reports: You have been spoofed!
On a darker and more critical security note, these reports will tell you if your domain identity is being spoofed by attackers and being used to pose as your organisation for phishing or other fraudulent purposes. These are the notifications that you really want to receive to head off fraud attempts and avoid disgruntled members of the public.
You can now see the activity when it occurs and formulate a plan with your information security and data protection stakeholders to deal with it.
Even on the occasions where you cannot set a DKIM signature to go with your email (some older mail servers and applications simply cannot handle DKIM), you will still benefit from seeing the DMARC reports.
Handling rejection… and other DMARC policy settings
Even the best ISMS professionals have to handle rejection at some point in their career. Thankfully with DMARC rejection is a positive thing. The “p” value is mandatory as it tells others how to handle messages that fail DMARC authorisation processes. There are only 3 options to consider:
The general advice, is to start with “none” until you begin to receive and understand DMARC reports. Only when reports have been analysed and understood should the policy be set to “quarantine”.
DMARC policy of Quarantine
When a message claims to be from your “domain.com” and fails the DMARC checks, then it will be quarantined to the percentage value that you set. The example below instructs quarantining 20% of the time (or any value you choose) so that messages can be reviewed by the recipient.
“v=DMARC1; p=quarantine; pct=20; rua=mailto:firstname.lastname@example.org”
The quarantined report messages are posted to the mailbox of the sender in the “rua” value in our example. In the real world of the email recipient, the message is likely to end up in their “junk” folder.
DMARC policy of Reject and the Day 1 mistake!
You should only set the policy to “reject” once you are confident that you have identified all of your domains that legitimately send email on your behalf. Be aware that these may be infrequent, such as a Christmas email message marketing campaign that goes out each year. DMARC caters for the gravity of this policy by allowing you to set a percentage, so that the rule is only applied to a subset of messages initially.
Setting the policy to “reject” is something to consider carefully as you are effectively telling a recipient to not even accept a message that fails the DMARC authentication checks. If you move to “reject” too early, you risk turning off the next payroll run notifications, the latest customer update messages, or the efforts by the marketing department, just as much as you will counter the activities of any attackers that happen to spoof your identity.
For Sandfordshire Police, a “reject” rule will look like this:
“v=DMARC1; p=reject; rua=mailto:email@example.com”
DMARC has a set of frequently asked questions including the incremental adoption of DMARC rejection.
Improving ISMS visibility by monitoring DMARC
Whilst you can manually review DMARC reports as they come in, this involves opening extensible Markup Language (XML) files and reading lines of laborious text. Because the XML data is received in a standard DMARC format, for those with a protective monitoring or SIEM solution it should be easy to collect and analyse DMARC reporting as another valuable source of security information.
DMARC information should be used for correlation and alerting against other systems within your network (a phishing campaign might be followed by an increase in unusual logins or account takeover activity). When DMARC reporting is received, you could consider using your SIEM to visualise and alert on spoofing and authentication failures that are being reported back to you.
This will be useful for monitoring the wider risk profile and convincing stakeholders of the value to get all of your legitimate domains into your DMARC approach, eventually getting to a correct “reject” policy and protecting your identity.
Quick summary of DMARC adoption as part of your ISMS
Good practice is to start DMARC adoption slowly and incrementally. If your domain admin has not heard about DMARC yet then give them this link: https://dmarc.org
This is the DMARC community site that goes into deeper configuration, filtering detail and scenarios.
The process to deploy DMARC is summarised as follows:
Here is a summary of the ISMS benefits and considerations that DMARC supports:
- Protect your identity by reporting and preventing forgery and spoofing;
- Inform other domains that you are using authentication checks;
- Reduce spam and malware getting through via email;
- Deliver cost effective cyber security, DMARC shouldn’t be expensive to deploy apart from the time and effort of your domain administrator – don’t forget “change control”;
- Receivers to establish that you use authentication and to know what your policy is should authentication fail;
- Incremental transition to a policy of “reject” based on analysis of DMARC reports;
- Security insight as even the lowest level of DMARC reporting will provide statistics that can be incorporated into wider protective monitoring.