Reduce Your Risk to Phishing with DMARC

Phishing attacks, by design, create stress and even panic in our hearts and minds. No one wants to fall victim to something completely avoidable. Everybody gets phished. Besides Awareness Training, which is arguably the most effective component of any Cyber Resilience strategy against phishing, what other things should we be aware of in the ongoing struggles to protect ourselves, our clients and the bottom line?

These are especially stressful during this time of the season to incoming first year college students who are already stressed out about getting up to speed in the new year, finding where all their classes are, learning the schedule, acquiring the right materials, making new pals and more. In the midst of all this, phishing attacks land in their inbox notifying them of problems with their loans and ask for them to verify some personal info. Many of them are sitting ducks for this kind of thing.

The same can be said for new employees at organizations, large and small. They tend to work fast, trying to set a good precedent in their first few weeks on the job. They think fast and click fast and more often than we think, click on links in phishing attack emails.

What can public, private, government and education sectors do to minimize these threats as part of their larger Cyber Resilience strategy?

There is an angle to minimize the threats posed by specific types of phishing, especially where the attacker poses as an organization, a university or business. This is why organizations should learn more about Domain-based Message Authentication, Reporting and Conformance (DMARC) and how to successfully implement it.

DMARC makes sure emails are delivered only from authenticated sources. This makes sure that any non-authentic sources (like phishing attackers) are blacklisted and prevented from delivering email into anyone inbox.

Why isn’t everyone using DMARC? DMARC isn’t easy to implement. It involves testing, testing and more testing. It is arguably one of the most sophisticated protocols in use today.

Depending on your email architecture, be it Office 365, Google’s GSuite or a mail server you host yourself, there are three components to implementing DMARC:

  • SPF Records – This record lives in your DNS configuration for the domain you use to send and receive email. It tells the internet which IP addresses are allowed to send email on behalf of your domain. It also helps cut down on the amount of unauthorized spam potentially sent from your domain. Every organization should use this component at the very least to prevent their brands (domains) from ending up on blacklists, which leads to interruptions in mail delivery and/or messages disappearing in the ether. Read more about SPF on Wikipedia.
  • DKIM Authentication – This adds another layer of authentication to the SPF Record. It uses encryption keys (public and private) to make sure the IP addresses sending mail on behalf of your domain are, indeed, the servers they are claiming to be. Read more about DKIM on Wikipedia.
  • DMARC – This is where things get complicated. DMARC combines SPF and DKIM to ensure the servers and messages are authenticated, end-t0-end. In simple terms, DMARC requires that checks against SPF Records and DKIM both pass. If they do, DMARC applies additional policy settings to ensure messages are delivered only when all of these requirements are true. If any one component fails, messages can be quarantined or rejected altogether. Read more about DMARC on Wikipedia.

So, while the first step would be to implement DMARC, a lot of learning about your email architecture is required to make sure nothing is overlooked, which can cause pretty serious problems when implementing DMARC. Then, testing, testing and more testing is required in order to get things working in a way that ensures messages are authenticated but also that legitimate messages aren’t being blocked. It’s not as easy as it sounds.

Here’s a scenario that might help illustrate: DMARC works great when mail is sent from a single source. Authenticating a single point of origin is pretty straightforward. However, DMARC gets tricky when organizations send mail from more than a single origin point. If your organization has mail servers around the globe, for example, configuring DMARC can be particularly challenging to ensure legitimate messages don’t get blocked.

While implementing DMARC is key, an important second step is also worth considering.  I always recommend registering look-alike domains that could be used against your organization in phishing attacks. For example, if an organization called buttwhack.com might want to consider registering butttwhack.com and buttwack.com, etc. This exponentially minimizes the risks that your organization will become a victim in a targeted attempt.

Again, the most important way to defend ourselves against phishing is periodic Awareness Training. Coupled to elevating your team’s awareness of the tools and tactics the bad guys are using, learning more about DMARC and if it’s a good solution for your organization is worthwhile.

WIMZKL would love to help! Get in touch.