2

I'm looking to monitor file uploads to the internet (mainly through web browsers) from our network. Specifically our application source files.

What is the best way to do this? I'm aware some DLP solutions exist out there today, but is there a better way to do this (read, cheaper) through any sort of mechanism?

mumbles
  • 380
  • 1
  • 2
  • 12
  • Products are no magic. If you are looking for a cheaper solution and have enough time, experience and developers you can create similar solutions yourself, i.e. sniff the network traffic, maybe intercept SSL and look for the content of HTTP uploads (in your case). But note that DLP products detect only simple cases of data leakage (i.e. not the advanced attacker who knows that a DLP solution is there) and that getting the know-how, writing and maintaining your own solution will probably cost more time and money than buying a product and support. – Steffen Ullrich Mar 03 '17 at 05:15
  • Or to get more into the technical detail: uploads using the web browser are done with HTTP (usually POST request, maybe PUT in case of WebDAV) and you can intercept these either with a proxy or by sniffing the network. With the right proxy you might even do SSL interception. But, at least in case of POST the upload is embedded in `multipart/form-data` which you need to parse. And of course, these are only the most trivial cases of a naive user uploading a file which don't protect against more technical users which scramble the data before upload or upload in chunks or similar. – Steffen Ullrich Mar 03 '17 at 05:34
  • 1
    This is ultimately hopeless, especially if you can't stop people from bringing in their smartphones, usb storage devices etc. I'd suggest you change your approach. Maybe making sure you can find out *who* uploaded something, eg by watermarking documents, and communicating that, might ultimately work better. – Out of Band Mar 03 '17 at 09:07

1 Answers1

1

If web browsers are your main concern, the 'simple' answer would seem to be setting up a proxy (e.g. squid) with SSL interception. And informing your users you are doing this.

But that (as others have pointed out) doesn't buy you all that much, beyond opening up the door to more possibilities.

With Squid alone, you would get the source, destination site/URL, and size/mime-type of the upload (and most likely, source code will be exfiltrated as a compressed archive, so the mime-type seems unlikely to be all that useful).

You can enable ICAP in Squid to offload deeper inspection to something else, but I couldn't find an open-source DLP solution that supports ICAP - there are commercial ones. It is possible to use ClamAV via ICAP, so possibly you could write some signatures in Clam to try and help with your use case.

Fundamentally, though, this is unlikely to really guard against people exfiltrating data (it is a matter of how determined/clever they would need to be, and I can't think of much that really raises that bar). It may be better to mandate a working environment that limits the opportunities to exfiltrate in the first place (e.g. use something akin to a bastion host/jumphost on which source code can be accessed and worked on, but hopefully not downloaded - copying may be difficult to prevent).

iwaseatenbyagrue
  • 3,631
  • 1
  • 12
  • 24
  • So not only is there no good home-grown solution... but even commercial ones aren't that great? I smell a business opportunity. Thank you for your answer, i'll take a look into the tech you mentioned and see if i can find a happy medium. – mumbles Mar 03 '17 at 11:48
  • I can't really speak for the commercial solutions as such, but in general, one issue would be that encrypting the data would render the DLP setup kind of pointless. You could also block uploads where the data had high entropy, but that seems prone to false positives (not to mention, causing grief to your users). Google Docs is an example of a different approach: remove the need/possibility for files to be taken off servers in the first place. – iwaseatenbyagrue Mar 03 '17 at 11:55