Securing Office 365 email

Emails have been proven time and time again as a consistent weakness in securing environments. This article is going to address methods to help secure your Office 365 environment.

Filtering incoming emails

The first recommended policy to create for your domain is a filtering policy for incoming attachments. With a filtering policy, we can identify and block extensions that should be deemed “dangerous”.

We are going to create (2) rules to address executable content and malicious extensions.

Within your Office 365 portal, choose Admin Centers -> Exchange:

exchange_admin

 

 

 

 

 

 

 

 

Within the Exchange Admin center, choose mail flow -> Rules :

mallflow_rules

 

 

 

 

Create a new rule by choosing the “+” sign and selecting “Create a new rule”

Important – choose more options

more_options

 

 

 

 

 

 

 

 

 

block_executablesName: Block Executables

Apply this rule if… Any attachment has executable content

Do the following… Reject the message with the explanation “This organization does not accept emails with executable attachments.”

Then save.

 

According to Terry Zink’s Security Talk site:

https://blogs.msdn.microsoft.com/tzink/2014/04/08/blocking-executable-content-in-office-365-for-more-aggressive-anti-malware-protection/

This rule blocks: com, dll, dos, exe, rar, jar, obj, os2, vxd, pif, and w16 extensions. Not good enough! We need to create a second rule to cover other dangerous extensions…

Let us repeat the steps: New Rule, choose “more options”:

block_malicious_extensionsName: Block malicious extensions

Apply this rule if… Any attachment’s file extension matches

Then specify a word or phrase for each extension type, clicking “+” individually per extension.

 

Recommended Extensions to be blocked:

ad[ep]
bat
chm
cmd
com
cpl
crt
exe
hlp
hta
ins
isp
jar
jse
lib
lnk
md[be]
ms[cipt]
pcd
pif
reg
sc[rt]
sh[bs]
sys
vb[se]
vxd
ws[cfh]

Other extensions can be added or subtracted – I compiled these from what Google automatically blocks, and from Microsoft Technet Article 24715.

Do the following… Reject the message with the explanation “This organization does not accept emails with certain attachment types.”

Save and allow an hour for the rules to go into effect.

Verifying email sources with DMARC

Office 365 utilizes SPF (Sender Policy Framework) by default, but this does not guarantee there are consequences for email that fails the SPF check. In this guide, we are going to implement DKIM to help verify the sources of your domain emails, and DMARC to allow us to create rules and reporting of our email as it is being delivered.

Before you enable DMARC, you will want a target to receive and parse the emails. I am aware of dmarcian https://dmarcian.com and Postmark http://dmarc.postmarkapp.com. Dmarcian will provide free reporting up to a certain volume. Postmark provides a free reporting service, with weekly reports sent for free. I am open to recommendations, and will append this post – especially if there is a decent open source parser out there.

You will need access to your domain registrar in order to implement DKIM and DMARC – both use DNS records. DKIM provides a validator mechanism, and DMARC provides a rule and reporting mechanism.

A typical SPF record for a domain will be a TXT record, with the following @ record:

v=spf1 ip4:8.8.8.8 ip4:4.2.2.2 include:spf.protection.outlook.com ~all

The breakdown of the above SPF statement is as follows:

v=spf1 if the SPF version being used

ip4:8.8.8.8 should represent the static IP(s) that email can originate from. This is used for customer sites to accomodate multi-functions  and non-authenticating email relays. Add a new entry for every IP address or range

include:spf.protection.outlook.com is trusting emails from outlook.com

~all is a soft fail. This is typically the recommended flag when setting up DKIM to help allow the successful delivery of outbound client email. Clients targeted with heavy spoofing may need to implement a hard fail of -a to help combat email spoofing, but will need to understand that legitimate failures will increase.

For DKIM, you will need to create two (2) CNAME records in the following format:

CNAME1:

Host: selector1._domainkey

Points to: selector1-infosoda-com._domainkey.infosoda.onmicrosoft.com

TTL: 3600

 

CNAME2:

Host: selector2._domainkey

Points to: selector2-infosoda-com._domainkey.infosoda.onmicrosoft.com

TTL: 3600

 

Finally, after you sign up with your DMARC parser, you will receive instructions on how to set up your TXT record. A sample for a PostMark DMARC record is below, with your string replacing “UserID”:

Host: _dmarc

TXT Value: v=DMARC1; p=none; pct=100; rua=mailto:re+UserID@dmarc.postmarkapp.com; sp=none; aspf=r;

The flags in the above record deciphered:

v=DMARC1 is the DMARC version being used

p=none means no action is taken by the receiver if the email fails the DMARC check. This should be the initially set flag for auditing.

pct=100 is the percentage of emails subject to the DMARC filter. This can be reduced to help control the amount of data being reported for initial implementation.

ua=mailto:re+UserID@dmarc.postmarkapp.com is where receivers send their reporting to (provided by your DMARC sparser)

sp=none tells receiver there is no policy for subdomains.

The Identification Stage

Now we must allow time for replies to our DMARC parser for our outgoing emails. If using Postmark, you can expect an email in your inbox with your results:

Postmark header sample

This will be a weekly report, which will break down sender IPs for you to help identify external sources using your email domain. Before you adjust your flags for how to handle your outgoing emails, you need to identify and include all sources, or risk having emails rejected or labeled as spam.

Spend time identifying the sources over the next few weeks, and making adjustments to you SPF and DKIM records to include external services, such as Mail Chimp. The steps to secure and confirm your outgoing email should be:

  1. Identify all sources, update SPF and DKIM records to include
  2. Set SPF to a HARD fail, do not enable DKIM or DMARC
  3. Verify email delivery
  4. Add DKIM and DMARC record
  5. DMARC should have “p=none” flag to monitor delivery
  6. Verify email delivery
  7. Set DMARC flag to “p=quarantine”, set percentage of emails (???)
  8. Monitor/verify email delivery
  9. Increase percentage to 100% in DMARC
  10. Verify/monitor email sources
  11. Set DMARC flag to “p=reject”, adjust SPF to SOFT fail
  12. Verify/monitor email delivery

Step 11 may seem counter-intuitive; please review the following Microsoft article explaining the logic:

https://blogs.msdn.microsoft.com/tzink/2015/07/12/what-is-the-best-combination-for-your-spf-record-dkim-record-and-dmarc-record/

Securing your email from spoofing (after enabling DKIM and SPF)

Within your Office 365 portal, choose Admin Centers -> Exchange -> Mail Flow Rules

Create a new rule, such as “DMARC Filtering”

The basic rule is:

Apply this rule if… The sender is located… Outside the organization.

AND

A message header includes… ‘Authentication-Results’ header includes “dmarc=fails”

AND

The sender’s domain is… ‘yourdomain.com’ Do the following:

Prepend the disclaimer… “WARNING – this email appears to be spoofed or other appropriate disclaimer”

AND

Set the message header value… Set the message header ‘X-Custom-DMARC-Action’ to the value ‘ETR to set SCL to 9 for spoofed domain’

AND

Set the spam confidence level (SCL) to… 9

AND

Generate incident report and send it to… your support/security incident email address

Multi-factor Authentication

Multi-factor authentication is the final step to help secure the environment. This is the most effective strategy against phishing attacks that try to steal credentials from your users.

Within your Office 365 portal, choose Admin Centers -> Active Users -> Select user. Option is near the bottom:

Multi-factor authentication navigation

Selection will drop you into the “bulk update page” allowing you to choose users. This should be slowly rolled out to verify behavior, typically starting with higher impact positions within the organization.

 

 

The above changes will help protect users within your Office 365 Exchange deployment.