End user composes email linking to external domain: Best practices?

Question

2 questions:

• What are the arguments against warning end users that compose emails linking to external, non white listed domains?
• Are there available tools, including handling of necessary dialogues with users, that intercepts e-mails as described below?

In the function as a corporate employee, I recently received an e-mail requesting me to fill out an online survey. An external tool was used, so that both the sender's e-mail address and the link to the survey was on an external domain. There was no link to an authoritative, internal site where this external site was white listed.

I assume you agree that this is not OK⁽¹⁾. Logically it would follow that one would train users not to compose such emails, as that will lower colleagues' vigilance. But when I bring this issue up with my managers, they respond "it's OK to click this link", no further action taken.

Would a solution here be to introduce, at the corporate level, a filter of sorts that:

• Monitor incoming e-mail that contains external links that are from non-white listed domains.
• Infer (from name or otherwise) if the sender seems to identify as an internal.
• Halt or append the e-mail (remove links, supply warning including 1) best practices and 2) list out the removed links in a way that require manual work in order to execute them, e.g. inserting square brackets around the TLD or similar).
  • Consider also appending e-mails including links to white listed sites, providing confidence and raising awareness.
• Warn the supposed sender about what has happened and again supply advice about best practice.

I would assume this would increase vigilance and make it harder to perform actual attacks, but I have not seen such a safeguard deployed for the clients I have worked for recently, all of which have experience with actual spear phishing attacks.

So again, the questions are:

• What are the arguments for not implementing said filter?
• Does any provider (e.g. Fireeye) provide such filtering⁽²⁾ OOTB, preferably supporting an ADFS & Exchange-based infrastructure?

^{(1) Rationale: The e-mail cannot be distinguished from spear phishing; anecdotal evidence suggests that even IT pros easily succumb to this attack form; spear phishing "[accounts] for 91% of attacks" [W]; mature corporations train their users not to click links to external domains that are not authoritatively white listed internally.}

^{(2) The functionality should include 1) reaching out to assumed internal users that, with good intentions, have used external tools to create bulk e-mail, as in the use case described above, and 2) managing an authoritative white list that can be made visible to end users.}

^{Note: Question has been rephrased from "Why don't we warn end users that compose emails linking to external domains?".}

Answer 1

One reason is that this kind of filtering will at some point annoy someone (possibly someone high up), and exceptions will start to be made. If the filter is felt to be negatively impacting the business, then I would assume the filter will go (or be scaled back), and you will still have your issue.

Having some kind of warning might work better (i.e. cause less friction) than blocking mails (or changing the links), but I would be concerned about how effective that will be, versus how much work it is to maintain.

One thing you might consider is demonstrating the issue, and pushing for user education. A good starting point for this is https://krebsonsecurity.com/2012/01/phishing-your-employees-101/ - which is basically a short overview of sptoolkit (the link for which no longer works). One seemingly viable (and still available) alternative is gophish (https://getgophish.com/).

In general, running periodic 'trainings' with such tools, and providing the users feedback about their actions is somewhat effective in raising awareness, and in encouraging critical thinking (to a point), as well as encouraging users to report anything suspicious.

Answer 2

There is no answer to the "why don't we" kind of questions because they are based on false premises: you're assuming that because you don't do it, nobody does. Specifically, there are plenty of mail security tools that will let you do things as simple as filtering mail based on regular expressions (which is enough to perform the filtering you're requesting).

Now, there are additional elements that you're not taking into account. For instance, an organization might use technologies like DKIM, SPF or even S/MIME to validate the authenticity of messages and help the end user assess the validity of messages. Since there is simply no way to prevent incoming mail from being gross forgeries ("hi, I'm Brenda from accounting. This is my private mail. Could you please...") the most efficient step for protecting your org is to teach users to look for positive identification markers (like the source domain name and, if possible, the digital signature of incoming messages).