Using transport rules as a security tool (Part 3)

This is Part 3 of our series on using transport rules as a security tool. Previous articles are linked in the table below:

Part 1 – Setting up the mailbox
Part 2 – It’s all about those transport rules
Part 3 – Reducing the haystack (you are here)

Refining transport rules

Hopefully you aren’t like me with over 3K messages… πŸ™‚

At this point, we should now have a shared mailbox full of messages (like above) that have been copied in due to testing our spam policy and our transport rules. If your organization is on the smaller side, there may not be much to look at, but even still, we want to refine our transport rules and start using Inbox rules so we can spend less time reviewing and more time doing other things!

You will notice certain patterns in spam and phishing attacks that can be added to your transport rules. Sometimes this is a specific phrase such as “<district name> Email Admin Team” or eventually end up with something like “(wallet|bitcoin|btc|cryptocurrency) (address|transfer|account|wallet)” to catch extortion emails that found one of your user’s (hopefully) previous passwords in a data dump. Once you’ve added these to the quarantine rules and evaluated, you can move these to delete which will help reduce how many messages you have to deal with in the shared mailbox. Over time, this will help you identify new campaigns and tactics faster and easier, and you can simply add them to the transport rules. Here’s what that might look like:

Keep only the junk you want!

You may have already noticed that the rules will sometimes pull in things like social media communications, random online services that your staff use, and other legitimate bulk mail. This seems counter-intuitive, but we want to add these to our allow list so that they end up in the Inbox folder. The issue here is that Inbox rules only run on items that hit the Inbox, not Junk, so we have no way to delete them automatically unless they end up in the Inbox.

Create an Inbox rule in the shared mailbox to delete based on key words, regex, headers, etc. in the same way that you do for transport rules, and simply add things like or to the list. This will help reduce the amount of things you have to look through, and it should result in faster response and less work overall.

The very first rule is delete anything that passed DKIM and DMARC for our domain to delete any legitimate email that passes in. Internal rule matches actually bypass this because the content is attached to the message, not in the incident report message.

There are some things that I just don’t feel comfortable moving into the always delete level of rules, especially if it could be something like gives a false positive and affects a business function like accounts payable. In these cases, I leave it set to quarantine even if it has never given a false positive. In the event we do get a false positive, we simply go over to the Security and Compliance Center and release the message from Quarantine. Once I feel comfortable with a specific part of a rule match, I’ll set up an Inbox rule to delete just these specific messages.

Looking to the future

An unfortunate truth about transport rules is that there is a limit to how many keywords or regex entries can be used in a single rule. In a smaller district, you may never hit that limit, but larger districts may hit that limit very quickly. Personally, that limit has been hit a few times causing me to have to create a second rule to add more, but when possible, I’ve also found that many of the keywords overlap, can be re-written, or can even be handled better via regex.

About every 3 months, I pull a list of all of our keywords and do a string compare to look for similar enough phrases where I can make regex handle multiple keyword strings. I’m sure this is more computationally intensive, but I think it’s worth it (especially if cloud hosted since it’s not our servers!). I do this review mostly to keep things clean and easier for my staff to look through and update the rules, but there is nothing wrong with just creating additional rules when you hit the limit.

In the my final post, I’ll cover alerting and responding to phishing emails, both an immediate manual process to get you up and running as well as possible ways to further automate the workflow. Stay tuned!

Leave a Reply

Your email address will not be published. Required fields are marked *