Forum Discussion
capability to detect password protected files to during the email delivery and ZAP process of the e
The detection is easy enough. There is a predicate that looks for attachments that are password protected, and you can combine that with another predicate that requires that the message contains a file type that is likely to give trouble so you can admit types such as DOCX or XLSX without delay. This will give you a few false positives for containers (typically ZIP) that contain password protected modern Office and legacy Office attachments in clear, because the predicates apply to the entire message rather than each attachment in turn. The same principle means that you cannot use the presence of modern Office types as an exception because the presence of one of these would allow the admission of containers that also contained password-protected legacy types or worse.
Also remember that passwords providing file write protection in Office and even cell protection in Excel also count as encryption for the purposes of detection.
You also have a lot of flexibility over the actions you take. You need not quarantine; you could simply prepend a warning disclaimer, or quarantine and send a message to your service desk to investigate the quarantined message. You might well want to start with a non-intrusive action that effectively just counts what your rule is detecting, so you know what to expect before you start interrupting any part of your mailflow. I personally use an EXO PowerShell get-maildetailtransportrulereport to read subject lines, but there are other options.
Regarding your follow-on question, the only related property mail flow rules have access to is SCL [spam confidence level]. I suppose it could be used as an additional predicate, but I would consider it too variable to be an effective measure if the risk you are addressing is whatever might crawl out of a password-protected attachment. You can certainly add your own predicate to apply the rule just to known troublemaker domains, but that is reacting to known threats rather than the entirely new ones adopted by serious actors.
Thanks for your insightful answer on this, but I think the Transport rule would work on this but we as admins should have to add those legit domains or add authentication Results in the Except field in the rule with SPF=pass.
So what's you take on this?
- Yes, exempting known good senders is also valid tactic, especially if the initial non-intrusive test shows that 90% of your incoming encrypted attachments are coming from a small number of known friendly domains. I still worry though when I receive a mail from a bank with the disclaimer "We take no responsibility for... " yada, yada. Did the admin copy and paste the text from their previous job, or are the bank's internal systems really that weak?
