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 blocking writing a temp file on a removable disk

I have a user who works in graphic design, they use removable disks a lot.

When they try to open for example an Indesign file from a removable disk, InDesign tries to write to the same directory a tmp file that it works on until the user saves the file, but Sophos blocks this with a popup saying a write has been blocked because it wasn't Explorer.exe doing the write.

For eg:

M:\IndesignDocs\2016_spring_newsletter.indd, when opened immediately writes to the same location as M:\IndesignDocs\~2016_spring newsl~2u3i6w.idlk

The log file says the following:

20160912 005324 A "block transfer" action was taken. The user tried to save or copy a file to a storage device without using Windows Explorer.
Username: doimain\user
User action: File save or copy
Data Control action: Block
Destination path: M:\IndesignDocs\~2016_spring newsl~2u3i6w.idlk

Nothing in Data Control is set to block, all 8 rules are set to 'Allow Transfer', I've moved this user to a new OU, and created a new Data Control policy with 0 rules, this is a temporary solution, if anyone could shed some light onto why this is happening that would be great.

Enterprise Console 5.4.0
Endpoint Security and Control 10.6



This thread was automatically locked due to age.
Parents
  • Hello JEFFERY,

    Allow Transfer
    should not result in the above action (please note that Allow on acceptance is a different thing). Nothing was blocked when I've tested it (though with only two instead of 8 rules). I'd suggest you turn on verbose logging on the endpoint (Sophos GUI, Configure data control. It should name the matching rule(s) which triggered an event.

    Christian 

  • Sorry, after checking, one rule did have "Allow On Acceptance", I thought it would prompt the user, saying something like "You are transferring a document marked as 'Sensitive', are you sure you want to do this?"

    Changing this to "Allow Transfer" fixed this, thankyou.

  • Hello JEFFERY,

    one rule
    thought as much [:)].

    I thought it would prompt the user
    well, it'd do if Explorer is used but for any other application the write is blocked. It's not immediately obvious why this is so - I'll try to explain. DC is intended to prevent data from getting outside and blocks transfer but not does not delete "forbidden" data - therefore the legitimacy must be determined before the transfer takes place and thus DC must be able to read assess the data while it's still "inside". DC covers transfer to a removable medium or to an application which potentially moves data to the outside. In the latter case it intercepts reads by known applications (with some limitations - please note that certain user folders might not be subject to DC as an application must be permitted to read user preferences and the like). In the former case though the content is usually not known before the write to the removable medium and thus any write by any application is blocked. The only exception is an Explorer copy where the source can be determined. So if a rule has block as (potential) action only Explorer is permitted to write.

    And BTW: Allow and log is not guaranteed to report all transfers to SEC and therefore will not provide a complete audit-trail.

    Christian 

Reply
  • Hello JEFFERY,

    one rule
    thought as much [:)].

    I thought it would prompt the user
    well, it'd do if Explorer is used but for any other application the write is blocked. It's not immediately obvious why this is so - I'll try to explain. DC is intended to prevent data from getting outside and blocks transfer but not does not delete "forbidden" data - therefore the legitimacy must be determined before the transfer takes place and thus DC must be able to read assess the data while it's still "inside". DC covers transfer to a removable medium or to an application which potentially moves data to the outside. In the latter case it intercepts reads by known applications (with some limitations - please note that certain user folders might not be subject to DC as an application must be permitted to read user preferences and the like). In the former case though the content is usually not known before the write to the removable medium and thus any write by any application is blocked. The only exception is an Explorer copy where the source can be determined. So if a rule has block as (potential) action only Explorer is permitted to write.

    And BTW: Allow and log is not guaranteed to report all transfers to SEC and therefore will not provide a complete audit-trail.

    Christian 

Children
No Data