Don't log non-uploaded files as uploaded

[Niklas (Niklas Netterstrøm Johansen)]

What is a one sentence summary of your feature request?

Don’t log files shown in a file picker dialogue as having been uploaded

Please describe your idea in detail. What is your problem, why do you feel this idea is the best solution, etc.

When trying to upload a file (or multiple) to a website, and you open the dialogue window to pick files for the upload (e.g., by clicking a button like “Select file”), the files shown in this dialogue will be seen as having been uploaded.

I’ve had this happen for a bunch of files I had in a folder, where all the files contained content monitored by a CAP policy via a Custom Content denylist.
Simply by opening this file picker dialogue, EPP saw the files and viewed them as having been uploaded even if I simply abort the upload without uploading any files.

Instead of viewing files as having been uploaded when they, in reality, haven’t been, logging a file as having been “uploaded” should instead be done only after said files have actually been uploaded.

How do you currently solve the challenges you have by not having this feature?

Currently, according to Netwrix, this is known behavior and cannot presently be mitigated.

The only real way to mitigate the mass-logging of files (both ones that got uploaded and ones that didn’t) is to drag-and-drop in the files that should be uploaded, instead of ever opening the file picker dialogue.

While this does solve the issue, the fact that users are unlikely to always drag-and-drop files for uploads means excess logging can’t be avoided.
Moreover, files that were uploaded through the file picker dialogue and files that were simply seen by EPP cannot be distinguished from one another.

Because of this, if a malicious user were to upload sensitive files via the file picker dialogue to, e.g., an unauthorized website, any unrelated files simply seen by this dialogue window would be logged just the same as the file/files actually uploaded by the user.
This makes it difficult to prove that the user uploaded sensitive files, not to mention proving which files were uploaded.

Upload any supporting images that you think should be considered in this idea.

[Niklas (Niklas Netterstrøm Johansen)]

I can also update this post with a little more info, after a bit of testing:

While file contents seem to get inspected when the files are shown in the file picker dialogue, the file name itself doesn’t seem to trigger a “file uploaded” log when the file is only shown, but it does trigger a log if the file is selected (even when it’s not uploaded).

Even just hovering over a file seems to be enough for it to be scanned and subsequently logged as having been uploaded.

Overall rather interesting, though still problematic.

[Zoran (Zoran Cocoara)]

Hi Niklas,

By default Endpoint Protector operates at the file access level, it has no visibility into whether a file was ultimately selected and sent or simply browsed past. From the EPP client’s perspective, the application touched the file and a scan is required.

I agree that this behaviour can generate some noise and it’s not ideal. There are two ways that come to mind that can mitigate this:

1. Enable “Advanced Printer and MTP Scanning” from Device Control → Global Settings. This reduces the file access events and reports only actual file upload events. Please note that this is a Windows only feature and the computer requires rebooting after the setting is enabled.
2. Enable Deep Packet Inspection (DPI) for browsers, Slack, and other supported applications. This eliminates false positives related to simply browsing for files.

Hope this helps, and please let us know your feedback once you’ve had a chance to test the suggestions above.

Zoran

[Niklas (Niklas Netterstrøm Johansen)]

I disabled DPI due to company needs, so I’m unable to test the second option.

As for the first, I am indeed in a Windows machine, so I tested this one out (after restarting, as you mentioned).

Unfortunately, the issue still persists, with simply hovering over and/or selecting a file still being enough for EPP to log it as uploaded, even though the file was never uploaded, and the upload was aborted.

[MihaiRosca]

Hi Niklas,

Thank you for testing both options and reporting back — that’s genuinely useful feedback.

With DPI unavailable due to your company’s requirements and the Advanced Scanning option not resolving the issue in your case, we don’t have a further workaround to offer at this point. You’ve hit the boundary of what the current implementation can do.

We’ve noted this as a feature request for improved precision in detecting actual file upload events versus file access events triggered by browsing. It’s a meaningful distinction from an audit and forensic accuracy standpoint and your description of the problem — including the DPI constraint — adds important context.

We’ll keep this thread updated if there’s progress to share.