Just need to verify that when ClickProtect policies are enabled, they override the organizational allow lists? We have a few clients that were a bit annoyed that when they had entries in their org allowed list, that the ClickProtect policies took precedence. I would tend to agree, unless I missed it, I could not find anything in the admin guide on this priority sequence.
ClickProtect has it's own allow list entry for exempting items from being affected by ClickProtect. The sender allow list is designed to only affect Spam and Content filtering, in order to prevent the allow list entry from being exploited to deliver attachments that violate corporate policies, or, URLs that can link to virus payloads or phishing sites.
My secondary question is, where in the admin guide (or Help) descriptions with either the org allow list and Clickprotect, does it state that ClickProtect takes precedence over the user and org allow lists. I have looked, assuming I missed it and a few clients want to know as well.
The help documentation for the Sender Allow list states that it exempts senders from content and spam filtering, and the help file for the click protect allow list tab specifies that the allow list is for URLS that should always be allowed. The ClickProtect sender allow does not take precedence over the sender allow list, because the sender allow list only exempts messages from content and spam policies. Any other of the policy tabs, virus, attachment, click protect, email authentication, are not affected by the sender allow list.
OK. However, if an allowed sender that will bypass content and spam filtering, sends an email with a URL that triggers a ClickProtect event and say a high risk is set to quarantine, then I would say ClickProtect takes precendence and that the same allowed sender will need to be entered a second time in the allow list of ClickProtect. Our users are questiioning why for other than viruses, can they not enter just once in the console, to allow a sender to bypass all other policies?
Believe me, I completetly understand the McAfee way of doing things, however changing the users/admins mindset of 10-years of Postini processing is a challenge. I know I bring that up more often than not, nonetheless it's what we have to deal with.
The ClickProtect allow list looks only at URLs, not the sender. Each URL would have to be allow listed.
The reason for this is that "trusted" senders also send out malicious mail, or are spoofed. Because SPF records are not always accurate (and can be spoofed as well), and DKIM is not widely adopted, the vast majority of Allow List entries are domain only, and are very often the cause of spoofed spam and malicious mail being delivered. Just this week we have seen messages spoofing Wellsfargo.com, and several customers allow listed that domain and had ClickProtect turned off, and had no SPF Record Validation, SPF Enforcement, or DKIM Enforcement in place. The result? End users recieved phishing mail. Our job is to limit the potential security risks. A phishing email delivered or an executable that isn't a virus itself but connects to a remote server and downloads a virus payload are security risks that hurt businesses, hurt our reputation (because the question becomes why didn't we stop it... even though the allow list is the reason), create more spam problems which hurts our customer's reputation online, compromise information of our client's customers, etc.
We understand that some customers would want a "deliver no matter what, except attached virus" list. It's tempting to do so. Until that trusted sender is compromised and blasts out thousands of phishing emails or virus payload links, or is the subject of a spoof attack that exploits allow list entries and is now spending man hours removing viruses from their LAN, repairing their IP reputation with hundreds of black list providers, contacting customers about stolen data, and generally having business come to a halt. A situation that happens all too often.
The SaaS Product is designed to be able to protect against those kind of threats. If a trusted sender is sending low-risk links, and ClickProtect is set to just pass those clicks on, then the negative impact will be minimal. If a trusted sender is sending attachments that violate an organization's policy, discussions can be made as to why those attachments are being sent and if perhaps another method is available (e.g. SFTP, Online File Transfer, etc.). With thoughtful configuration and routine review of policies, an organization can achieve their goals without relying on unsecure methods such as absolute allow lists.
I could not agree more with your response and it is going to be a template answer to our client base. No matter how much we try to protect our clients, in some cases they seem to want to undermine the reason they have this level of filtering.
Another issue with SPF Record Validation, SPF Enforcement, or DKIM Enforcement, is that a new wave of spammers are using throw-away domains with published SPF/DKIM, spoofing client domains and others, with embedded graphics and minimal word-salad content to bypass Bayesian filters.
Exactly, Frank! These guys are getting trickier and tricker, and as people become more tuned to what is 'obvious' spam, they're finding new ways to deliver their scams, their attacks, and all of the other garbage. It's a never ending race we're all in, and quite often it requires painting the big picture to admins and users that 10 minutes of annoyance today is better than 80 hours of panic and hard work later. Because a successful attack is not about "IF", but "WHEN". At some point a phishing email will be successful and gain credentials to a company's proprietary documents via a well-meaning user. At some point a virus payload will be installed by accident. Mitigating disaster to the best of our abilities takes resolve, constant observance, practice, compliance, but above all, resisting the temptation to take the easy road now.
It's something I've learned from years in Disaster Relief with the Red Cross, training in my local Community Emergency Response Team, and time spent as a support volunteer for a fire department. Just as an example, the folks who get to come back to their homes after a wildfire are those who planned ahead, took the steps needed to minimize and mitigate loss, planned for the enevitable evacuation, protect their assets, and swallowed the occational bitter pill (such as cutting down a tree too close to the house, removing the asthetic value in favor of defensible space). The same is true with computer security. The occational annoyance versus deep business impact recovering from a security compromise. The tree in the yard, or the house after a wildfire.