Data Loss Prevention

I am seeing an issue with DLP Endpoint 14.6 where files saved into the Autonomy iManage document management system are being corrupted.

The local copy is fine and the network copy is corrupt. Theoretically this happens when iManage transfers the local copy to the network storage.

The DLP endpoint agent configuration in the "channels to monitor" section is set to not monitor local drive and copy to local or network shares. I even pulled FINEST logging for two machines where this happened and support looked at them and confirmed that they are not touching the file.

As you can imagine, this means that the DLP endpoint agents are disabled until it can be proven that it is not the culprit or until it can be proven to be fixed.

Does anyone have any insight or suggestions?

I would use Process Explorer, run it when copying of files take place. Then understand what handles/dlls are injected by the DLP application into the Autonomy iManage application core files.

My best guess is that - its might even be Autonomy iManage unable to sustain/tolerate DLP scanning on its application files and considering it as 'consistency failed' during checksum validation. So support's claim that we are not modifying anything might be true. Its the Autonomy iManage that probably needs to understand DLP scanning as not-modification (mere guess in the absence of actual debug level data)

Many times this has happened with me for other applications ofcouse and they say - "the scope of checksum/hash validation needs alteration"

My two cents, kindly ignore if already known.

iManage says that the client application transfers the file to the iManage server over TCP 1081 and then the server does the actual file write via SMB2.

Considering this is not a client file write, turning off monitoring of the local/copy to local/copy to share channels may have no effect. I.e. The channel used may be proprietary. Looking online, I see only references to trojans in relation to the port.

This traffic from the client application to the server either falls entirely outside of what the DLP agent monitors or falls within the monitoring view, but there are no configuration options to pick a protocol and port to monitor or ignore.

EDPA extended logging generally clarifies: if there is a scanning issue like you mentioned. Since you already have a case logged with Symantec & that they have confirmed no modifications via/from DLP, this should have been already covered, I believe.

Workaround for DLP 14.5:

Please disable Network Access for the application saving the document to iManage.

Workaround for DLP 14.6:

In DLP 14.6, the Network Access was split into two separate protocols, HTTP and FTP.

Disable HTTP for the application saving the document to iManage.

The way to solve this is to whitelist the worksite folder and it will mitigatet problem.