Thread Info
  • State Verified Answer
  • Locked Locked
  • Replies 5 replies
  • Subscribers 1 subscriber
  • Views 21021 views
  • Users 0 members are here
Options
Suggested
This discussion has been locked.
You can no longer post new replies to this discussion. If you have a question you can start a new discussion

Data control not allowing save to USB device from application

joe90bass

Is this restriction a known issue or by design? I've set up a rule to ask users to authorise save to removeable storage and e-mail attachment of a document when it contains "surname firstname and fft" i.e. personally identifiable information of pupils. It works great, except that any document now saved directly to removable storage from an application is blocked. It appears from the knowledgebase that this is known about. Is there a workaround? To get users to save to the PC/network first and then copy to a USB device is going to get me shot!

:721


This thread was automatically locked due to age.
  • 0

    Guess John (Stringer) can (and will) tell you more.

    My answer is: by design. When you select either acceptance by user or block as action it tells you: These actions forces all transfers onto monitored storage devices to be made using windows explorer.

    IIRC you can't even create an empty file on the device in this case or use (DOS) copy - can't check right now.

    Christian

    :728
  • 0

    Hi,

    Christian is correct - this behavior is by design. We're intercepting files via Windows Explorer to ensure that data is inspected before it touches the removable storage drive (obviously quite important from a compliance perspective). To ensure that files copies go through Windows Explorer, and can therefore be intercepted, we block direct saves from applications when a "request user authorization" or "block" action is selected for the data control rule. If a monitor only action is selected such transfers are not blocked. A notification message is shown to inform the user to save the file locally and transfer using Windows Explorer. Hope this helps - great to see Data Control being used to detect PII within your organization.

    Best Regards,

    John

    :751
  • 0

    Thanks for the replies. Based on what I read, and saw on screen, I guessed it was behaving as designed but wanted to double check! I'll have to have further discussions with management here before implementing this, it will cause headaches for staff (and subsequently me!) as a large number of staff do save documents straight from applications to USB drives.

    Have to say though the ability to scan in this way and identify documents which contain personal information is brilliant! I guess it's going to be a pros v cons discussion!

    Thanks again

    :783
  • 0 in reply to Johnstringer
    I realize this thread is 5 years old, but I have this same question in to support right now. Has anything changed in the last 5 years. Is Windows Explorer still the crucial middle-man?
  • 0 in reply to DC_IT_Manager

    Hello Adam,

    Windows Explorer still the crucial middle-man?
    I'm just a customer so this is not an official explanation. In short the rationale is: In order to make a decision the final document must be available to the DLP software. In case of a save from application this is only true after the document has been written. At this point DLP can only delete the file but might not be able to inform the application of this fact. To the user the save has succeeded but the file isn't there - an unacceptable situation. Explorer is "universally" available, it's possible to determine what it's up to and furthermore the source is on hand for inspection.

    Christian