Enable Data Control for users to Allow/Deny known safe file attachments

Hello James,

I'm not a Central user so my knowledge about specific details of the UI and its behaviour is limited.
Nevertheless the workings of DLP are the same in all products. First of all, DLP isn't "enabled by default" - someone must have created a policy with one or more Data Loss Prevention Rules. When all the conditions in a rule are matched the specified action (AFAIK allow, allow on acceptance, or block) is taken. As said, I don't know the UI details (in the on-premise product you can for example turn off the blocked messages) but Action denied doesn't look like a message from DLP but rather from the application.
You should see corresponding DLP Events in the Central console - they should show the rule and action taken. Apparently it doesn't work as intended but by reviewing the policy, rules, and events it should be possible to determine whether it works as specified (and the policies/rules have to be amended) or not in which case some investigation would be required.

Christian

Hi Christian, and thank you for your message.

We actually just switched from the On-site Enterprise Console to the Hosted Central/Cloud solution.  When we were using the Sophos Enterprise Console system (initially installed 3 years ago) we have never had this issue ever reported to us.

Only after migrating over to Sophos Central, did we start receiving calls where users would attach a file, typically PDFs as those are more common that other MS Office documents, and not every PDF, but it appears to be only ones containing personal/financial/sensitive data. (i.e. Tax Forms, Bank Statements, etc...)  that when these files were attached to an email, (either by dragging and dropping into a new mail message, or using the "Attach File" button) did the user receive a pop-up (resembling almost an error message) stating, rather generically, that they didn't have permission to perform that action, and contact the network administrator.

At first we though that perhaps it was file and permissions errors (as the message that appeared in Outlook stated).  But when reviewing the file, and comparing it to others in the same location - and the other files here CAN be attached to the email without the message pop-up, we found that the user's permissions are identical.  Even when the file was re-created/generated, we could produce the same error, even when a Domain Admin who has FULL permissions, they would get the same message when attempting.

We then went to the Sophos Central web console, and reviewed the event log for the PCs in question, and the corresponding time would match up to the event log message of:

An ″allow transfer on acceptance by user″ action was taken. Username: DOMAIN\User Rule names: ′General organisation activities [USA] - Person identification numbers [USA] - 0′ User action: File open Application Name: Outlook Data Control action: Block File type: Document (PDF) File size: 1683200 Source path: \\SERVER\Folder\File.pdf

(Above message Syntax is the same, yet sensitive data/file name/User/Domain/Server info were changed to generic so that I could post it here)

It was noticed that when we bypassed the Data Loss Policy, was the user able to continue their process.  Our Admin was attempting to find a means of keeping everything intact, but was wondering if there was a possibility where it would prompt the user to either give the "OK" to attach the file, as almost like an "Are you sure?" warning message, or perhaps give a more SPECIFIC message to the user of "You are not allowed to send this file as an attachment due to a SOPHOS PROTECTION RULE" so that they are aware of what is causing the issue, as the message that is currently being produced appears to be more of an "Error due to File Permissions" more so than "Sophos Imposed".  When reviewing the DLP Rules, it appears that EACH of them give three (3) Options, of either "Allow the transfer," "Allow the transfer if user confirms," or "Block the transfer".  But it appears, that each of them all have the "Allow the transfer if user confirms" selected.  Which, I believe is where his confusion is coming from.   

I hope that this was more clear, as I apologize for any confusion, and I greatly appreciate your assistance.

Regards,
-James

Hello James,

thanks for the detailed description.
Did you ever see a Data Control pop-up after migrating to Central? From the log (Data Control action: Block) it looks as if the user had selected block. For the On-Premise version ALmon.exe (that displays the taskbar icon) is presenting the prompt. Don't have time to test right now what happens if ALmon is not active.

Christian

Hi Christian,  and thank you again for your response.

The only message that pops up is the message that indicates that the user does not have permission to perform the action, similar to the one below.

We are not getting any other pop-up messages.  The funny thing, is that the work-around (without turning off the DLP rules) is to use the "Send to Mail Recipient" option when right-clicking on the File in question from Windows Explorer.  It will send it as a plain text file, but it does not cause the pop-up message.  That is why we are looking to see what may/may not be setup correctly, as any message like the one above, does not say WHY the file cannot be attached, nor indicate that it was Sophos was doing the blocking.

-James

Hello James,

as for the Send to ... please see Known limitations with data control. Can't say why you don't get the pop-up with Central (you should get it otherwise what use would have Allow on acceptance?)
With SEC you can turn off Desktop messaging, time permitting I'll test how it behaves when a) messaging is turned off and b) ALMon.exe isn't running.

The message you see is clearly the result of the file being blocked - you'll likely get it anyway but with the preceding Sophos message it'd be comprehensible.

Christian

Hi Christian,

Thank you very much again for your message.  Yes it definitely is associated with the file being blocked (as we determined only from testing, as when we enable the rule to be enforced, that pop-up appears and blocks the user from even attaching it to an email, and when disabled, it allows the attachment).  And as you can see, the pop-up message we are receiving is not quite descriptive as to give the user an idea as to what is happening, as it does not mention Sophos anywhere, and looks like a typical Windows Error message.

Yes, I do remember the ALMon.exe file that was running when we did have the SEC solution, but since Migrating over to Sophos Central, it may be something different, as I do not see it during my searches.  And, yes, we, too, are curious as to why the Sophos branded messages are not coming up when the file get's blocked, as it would be nice to help the user get a little more feedback than a "Permissions Error" message.

Thank you very much, once again, Christian.

Regards,

-James-

Hello James,

as SEC Central allows custom messages (up to the same 100 characters). Thus the pop-up is essential. Can't say which process is supposed to present it, jak has experience with Central, I'm sure he/she (gender not set) can give you some advice.

Christian

Hello James,

as SEC Central allows custom messages (up to the same 100 characters). Thus the pop-up is essential. Can't say which process is supposed to present it, jak has experience with Central, I'm sure he/she (gender not set) can give you some advice.

Christian

I've not read the entire thread in great detail yet but can you check that Sophos detours module is being loaded into processes?

The easiest way would be to download Process Explorer [https://technet.microsoft.com/sysinternals/processexplorer.aspx] and the lower pane can show you the modules loaded.  Do you see the sophos detours DLL module in say IE, Chrome, etc...

Do you see the issue with computers with Secure Boot (technet.microsoft.com/.../hh824987.aspx) enabled and not with others?  Reason being that the appinit inject method doesn't work with secure boot.  Without the detours DLL not being loaded you get odd behaviour with Data Control.  

Regards,

Jak

Hello James,

as Jak has said, you get odd behaviour when sophos_detoured.dll (or the _x64 version) isn't loaded but not no prompt (rather several in a browse-select-upload/attach workflow).
I've tested with ALMon.exe not running and as expected you don't see the prompt, Data Control's action is Blocked by user, and you get the Action denied pop-up. If ALMon.exe is running there's perhaps a DCOM issue.

Christian

Hello Jak & Christian,

Thank you very much for sending in the messages.  And thank you for the process explorer app.  (though, sorry I couldn't get the Secure Boot link to open from the link)

At our facility, for the Windows 7 PCs, we do not have secure boot in the bios enabled, but on the Windows 10 PCs, I believe they are shipped to us with it enabled by default.

When I review the Process explorer, I do not see the Sophos Detoured DLL loaded.  I see it has the SophosOfficeAVx64.dll when I highlight a browser process, SavShellExtX64.dll for when I highlight the Explorer.exe process, and then when I highlight System, I get a few:  SophosED.sys, savonaccess.sys, swi_callout.sys, sdcfilter.sys, sntp.sys.

When I look at the running processes I see running:  

• Sophos Administrator Service
• Sophos AutoUpdate service
• Sophos Data Recorder Software
• Sophos Device Control Service
• Sophos Endpoint User Interface
• Sophos Health Service
• Sophos Heartbeat Service
• Sophos MCS Agent Service
• Sophos MCS Client Service
• Sophos Network Threat Protection Service
• Sophos System Protection Service Executable
• Sophos Web Control Service
• SophosClean
• Sophos Web Intelligence - three (3) Instances listed

I do see the DLL on my system when I do a file search, but it does not appear to be running. (32 or 64bit versions)

When it is mentioned about odd behavior, would this be a similar reason why we are seeing some users not able to be connected to LogMeIn Rescue, as they get an error message when attempting to run the file that is sent via LogMeIn when attempting to use this platform for remote assistance.

Thank you, both, once again, for your assistance thus far, as we greatly appreciate it, and please let me know what else you may need or like me to try.

Best,
-James