Scenario 1: Existing sensitive / non-sensitive file from USB or Network share opened OR
Scenario 2: A sensitive file is copied from Endpoint local drive to a USB or Network Share using Command Line where a non-sensitive file of same name is already present
- When a user opens an existing file from USB or Network share, DLP gets notification about this File Open operation.
- DLP saves a snapshot of the file on a temp location on the Endpoint.
- If after adding the new data, the overall result is such that the file that will now be saved to the USB or Network share is found sensitive, then in cases of Block type response rule, the Block action will take place.
- Due to this, file copy operation fails.
- Since the file copy operation failed, DLP by default always quarantines the user file (the file that user wanted to save) to a ‘My Recovered Files’ folder (as seen on the Block popup) in its original format along with an associated Readme file. No Quarantine response rule is required for this action to take place because DLP is programmed to do this ALWAYS.
- Finally, depending upon the Agent Advanced setting FileSystem.ENABLE_FILE_RESTORATION.int, DLP again copies the previously saved snapshot file back to the Network Share. Default value of this setting is 1 which indicates that the snapshot file will be restored.
Scenario 3: A sensitive file is copied from Endpoint local drive to a USB or Network Share using Explorer where a non-sensitive file of same name is already present
- When a user copies a sensitive file from the Endpoint Local Drive to USB or Network share, DLP gets notification about this File Copy activity.
- When the user copies the sensitive file to the USB / Network Share, then in cases of Block type response rule, the Block action will take place.
- Due to this, file copy operation fails.
- Note that in this case alone, the file quarantine action DOES NOT take place.