Sophos Central Data Loss Prevention "allow file transfer" Events not showing

Hello Kramarite,

first of all, Data Control is not intended as a monitoring tool. AFAIK, for a rule with an unconditional Allow action, matches (not necessarily all) are logged locally  but no events are sent to the console (Central Admin or SEC for on-premise).
Just curious - what is your rule that catches all USB file transfers? A File rule with wildcards?

apparently messages require the user to have local admin
I'm not aware that this is the case, wouldn't make much sense to require that users have admin rights. There's a thread from two years ago that describes this issue, whether and how it has been solved is not known. Events for prompted or blocked transfers should be sent to the console though.

Christian

Hello Christian,

 Thank you for your reply. If Data Loss Prevention policy is not intended as a monitoring tool, it does everything needed to be one except to pass on the events to Sophos Central. If Sophos Endpoint is not meant to report allowed transfers, then not seeing any makes sense. The confusion then becomes why it did so at all. The following are images captured today of what I'm seeing in Sophos Central - Endpoint Protection during the policy rule creation:

As you can see it's just a matter of clicking the checkboxes for the relevant filetypes. No doubt these are not the equivalent to a wildcard and do not catch all the file types but it's all that is offered within the policy.

Next are the reports/logs pertaining to the DLP rule:

I'm confused as to why these two users are in the reports without others also being present. They have the same general policy applied as the majority of staff.

This is the local events from my test a couple of days ago:

As for the local admin issue with msg prompts, I did see that particular thread regarding admin rights during my searches and will be exploring/testing further. Probably best to create a separate thread if help is required.

I think I have answered this one myself. This issue does seem to be similar, if not the same, issue as the old post you provided the link to.

As stated in that old post, there is a compatibility issue with systems where secure boot is enabled:

"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."

A bit of searching confirms that secure boot disables AppInit DLL infrastructure which per the old post is the method of providing the message popups.

Testing, I found that a system without secure boot has sophos_detoured_x64.dll running in a quite a few process's. Copying files with the DLP policy allowed, prompted to allow/block or blocked worked as expected and Sophos Central has registered each of those events in it's DLP logs/reports. Testing a system with secure boot, that DLL is completely missing from all process's and attempting the same actions with the same DLP rule in place results in: allows works as expected, both prompt to allow/deny and block ask for admin rights and displays a no permissions error even when admin credentials are provided. Interestingly, none of the secure boot systems DLP events are registered in Sophos Central logs. 

I'm guessing this is part of the "odd behavior with Data Control" mentioned in the old post. Just how much of Sophos functionality uses the sophos_detoured_x64.dll and thus requires secure boot to be disabled?

Hello Kramarite,

yes, it's Secure Boot - whether DLP will be re-implemented remains to be seen. See also How Sophos uses Microsoft Detours. Can't say why these particular events appear in the console.

File types are "True File Types" - the scanner infers the nature from the contents, not the name. E.g. if your policy is set to block executables and you rename program.exe to NotAProgram.jpg DLP will block an attempted transfer. If v.v. you rename AnImage.gif to MyProgram.exe it will be permitted.
OTOH File Name refers to "how the file is called" (the term name is overloaded, particularly in Windows). Thus if in the first example you add two File Name exclusions, NoAProgram.* and *.exe, neither will be blocked.  

As to monitoring:  As far as Endpoint is concerned Sophos' stance is that users should be aware of its existence and that it shouldn't permit general auditing. Where Desktop Messaging can be disabled (e.g. Application Control) a user nevertheless notices that an application is blocked. Furthermore there is no conclusive evidence that the user actually tried to run the application. Central collection of allowed data transfers would indeed permit to "spy" on users.

Christian     

Thank you for the info, your time, effort and patience. Somehow missed that knowledge base article in my searching, approaching from the perspective of missing logs. Ended up reinventing the wheel :P