We'd love to hear about it! Click here to go to the product suggestion community
I have been tasked with setting up a new peripheral control policy to restrict access to removable storage devices. The access has been set to "control access by peripheral type and add exemptions". Our secure removable devices has been setup to "allow" and we are able to copy to and from and write to files stored on encrypted USB keys.
The issue we have run into relates to removable storage devices. The policy is set to "Read only" and we are not able to edit a file on the the removable storage. But we are able to copy to and out from the removable storage. I need to be able to prevent the movement of files on and off of unencrypted storage.
My hunch is that this could be controlled with the use of an additional data leak protection policy. We are currently using UEFI secure boot across all machines and found we were getting similar issues covered in the follow link. As a work around we disabled our "default" data control policy which resolved this issue.
Has anyone had to configure a similar scenario?
this is not exactly Intercept X, is it? As far as behaviour is concerned it would fit Endpoint, the product is - I assume - Central.
Now, the cited article mentions only DLP and BOPS but not Peripheral Control. The latter works by disabling or configuring a device accordingly, it does not act on a file level.prevent the movement of files on and offRead only is exactly this - it permits reading and thus a copy from a device. If you want no movement at all why don't you Block this category? It should not permit a copy to the device, that's definitely not how it's supposed to work. Just tested with a run-of-the-mill stick, paste first asks for administrator permissions and then nevertheless fails.
In reply to QC:
We are indeed using Central Admin. So in essence, what I am trying to achieve is not really an option with peripheral protection. A read option provides the level of access required to copy and paste files to and from the stick.
In reply to kevin Whiteman:
no, read only should not allow a copy to (and, as said, I have not been able to paste onto a device that had a read only policy applied).
Apologies for my slightly mangled thinking but we are only trying to prevent a copy to (paste to the USB). Even with the read only policy applied we are still able to paste from another disk onto the device. Writing to existing files on the USB disk are blocked though. I have revoked and restored the policy but it still results in the same behaviour.
able to paste [... w]riting to existing files [...] blockedhm, sounds strange. Can you create a new file with Explorer? And can you delete existing files?
I can create a new .txt file via explorer. But if I edit it and save it am not permitted. Files can also be deleted.
this is definitely not the expected behaviour. BTW - which Windows version(s)?If you set the policy to Block for the non-secure devices - is indeed the device disabled? This would show that the policy is correctly applied. If so, then there's a problem with permitting read only - or rather disallowing write. Dunno how the Central version interacts with the user but I assume Device Control also pops up the balloon telling about izs intervention when you insert the device (or change the policy).
We are seeing this behaviour in both Windows 7 and Windows 10 1709. I changed the policy to block and it performs as expected. You are correct regarding device control in that interventions are displayed.
I have a call in the system with Sophos so will see what they can unearth.
a call in the system with Sophosthat would have been my suggestion. So it's not Windows 10 (I've only tested on Windows 7 Enterprise). As I'm curious I'd appreciate it if you could follow up when it's (hopefully) solved.
I will keep you up to date of any developments.
The issue reported in this thread is resolved once the other peripheral exception policies were removed and a single policy with a read-only rule is set to the client.