ExchangeDefender Phishing Firewall goes online tomorrow, and we wanted to explain our policy and our implementation of the URL rewriting/redirection because it is a departure from a traditional IT hierarchy where organizational policies override group and user requirements.

Our goal with ExchangeDefender PF is to provide a level of alert and notification to our clients that is designed to provide additional information about the link they clicked on. As we scale this service out, that will be it’s purpose: Be aware of what you clicked on, and prepare for what you’re about to see. Phishing, and spear phishing in particular, is designed to be a convincing fraudulent identity theft of an organization you know and trust (your bank, your coworker, your vendors) and our goal is to help you discern if something is valid or not.

Our whitelist/blacklist implementation is in line with “we inform, you decide” mantra, as we cannot outright block you from actually going to the dangerous site. That is the responsibility of your IT department, your network management, and your organization.

How do Whitelists and Blacklists work?

In ExchangeDefender we have 4 sets of whitelists and blacklists: user, domain/organization, service provider, and global. Our global lists are automatically populated for our service providers and when they protect a domain with ExchangeDefender, those entries are applied on the domain/organization level, and further down to the end user. As we continue to monitor, manage, and get additional intelligence about dangerous sites we will continue to curate these lists as a part of the service.

For example, we might find out that *.vlad8150.microsoft.net is a Microsoft Azure instance that is attempting to spread malware. We will promptly add it to our global blacklist and that site will now be blacklisted for every ExchangeDefender user. When they click on a link that leads them to that domain, they will see the ExchangeDefender PF notice with the URL in red. User will then have the option of ignoring it and proceeding to the site, or adding it to their whitelist. If they whitelist a domain/web site, any future requests will bypass ExchangeDefender PF web site and automatically redirect to the target URL.

The hierarchy of whitelists/blacklists is as follows, whichever rule is defined on the top is the one that is applied to the user when they click on a link.


But why, why not implement policies like NTFS, access list, or any other policy in which global deny rules override end user policies?

Simply put: Traffic blocking should be done on the network level. We are simply the alert service, we will advise you when we see something dangerous and it’s up to you to discern if the site is trustworthy or not. We believe that this implementation will cause the least amount of interruption to the day-to-day use.

That said, we have been working on additional controls and policies to help our service providers and CIO’s better enforce company security policies. As with everything, security policies must be implemented in layers – and dangerous content should be enforced in accordance to business requirements. This means that if your clients should not be downloading .exe files, the network firewall should be doing that. We don’t have the means to do that as an email service – users can right click on the email, put it in notepad, remove https://r.xdref.com/url= from the link and go straight to the web site.

How do we manage them?

ExchangeDefender PF whitelists are available at every level of ExchangeDefender. Simply add a site to either a whitelist and blacklist and ExchangeDefender will automatically propagate your rules down through the entire organization. Users will have the ability to add / block sites from the ExchangeDefender PF in real-time and their settings will be preserved in their account only.

Service Provider Level
Domain Level

P.S. Officially the service goes online tomorrow, unofficially it’s been in place for months we just haven’t rewritten a single URL except for the emails you received from us – we have worked very hard on the implementation and we don’t expect major problems but will have staff on hand around the clock to address any issues immediately. Spear phishing is an epidemic, over 90% of compromises start with a link in an email. We will handle any glitches, bugs, and issues as fast as possible and have full confidence that having an alerting service with potential problems is far more useful than having nothing and leaving clients exposed.