Put domain Spoofing emails in their own categories
Answered
Right now, the [[domain]] tag on domain spoofing emails cannot be modified. However, there are a number of templates in existing libraries that have templates using this feature, which is problematic for those who don't want to send users domain spoofing emails.
External emails that spoof our domain are blocked automatically by our spam filtering service and we carefully monitor the email sending behavior of internal accounts in order to mitigate the impact of account takeovers. If users cannot trust internal domain emails and are forced to treat them with the same scrutiny as external emails, we risk our IT department being overwhelmed by users asking us to validate the legitimacy of perfectly valid emails, sent from other internal users. This reduces our IT department's ability to respond to real phishing threats and reduces user productivity.
We understand that internal threats are possible and users should in theory be as suspicious of internal emails as they are of external ones. Its our determination that the cost of having users act with such skepticism is not worth the potential benefits, especially given the other security measures we have in place to prevent internal domain spoofing.
There are several ways to address this:
- Move domain spoofing emails in to their own categories: This increases the number of categories, but does not reduce functionality for users and requires no development effort to implement. This is the easiest option.
- Allow users to "Enable / Disable phishing email templates based on certain attributes". This requires development work, but effectively resolves the problem, along with other potential problems users might have.
- Allow users to change the default [[domain]] value. This would be useful because we could change the domain value to a misspelling of our domain, which is a realistic type of attack we'd like to train users to recognize.
At the very least, option 1 above will resolve the issue quickly and easily, though both options 2 and 3 are better in the long-run.
-
Official comment
Hey Alex,
Thanks for sharing this request her and expanding on it further! I've gone ahead and contacted our internal documentation team (which handles the categories and templates within the KnowBe4 platform) to review the details of this post. As you mentioned, this may be a quicker solution in the meantime while our development team considered further backend changes or deployment. :)
Thanks so much for this! Please keep an eye out for any changes or feel free to follow up in a ticket with our tech team.
Cheers,
Kaiser
KnowBe4
Comment actions -
I'd like to add that we are in the same boat and the Phish of the week and regular template updates keep forcing these on us when we block domain spoofing. To block the entire category or a simple slider to turn of Domain Spoofing templates would be greatly appreciated. These also do not get Tagged external because we force knowbe4 to be whitelisted internal. All of this works against the intention of the program, especially in a large company.
-
Michael - We set up a transport rule in Exchange to address these emails and quarantine them and it works well, even though we too have KnowBe4 emails whitelisted. You could probably employ a similar rule to mark these emails as external, while still keeping these PSTs whitelisted. Let me know if you'd like information on how this can be set up.
-
Hello All,
I have somewhat of an update on this item we recently added the ability to Disable attack vectors of our phishing templates.
Currently, that feature only covers attachment vectors but, I believe we are intending to add the feature to exclude spoofing email templates as well. I'll keep an eye on this item to see if/when that portion of the feature is added!
Please sign in to leave a comment.
Comments
6 comments