I've been looking at several data leak/loss prevention suites but, in their documentation, I'm unable to find how they treat HTTPS.
One of the 'leakage vectors' is sending information to webapps through HTTPS. In which case, the only way to detect the leakage would be to decrypt it.
But, to do that, it would have to impersonate the remote server, using fake certificates, like a man in the middle attack. To avoid users being suspicious or complaining, I guess the coroporation needs to insert their certificate as a valid CA on the company owned devices' browsers.
My questions are:
- Has anyone first-hand experience on this kind of scenario? Can you tell us how do you implemented it?
- Am I right or is there another way of managing HTTPS (for example, detecting the data in use at the desktop level with an agent)?
That's not "like" a man in the middle attack, it IS a man in the middle attack.
You implement it using a proxy server that will substitute your own cert for the remote cert. In the process, their browser will throw up errors about the cert not being valid. That is the point behind HTTPS and certification. So if you have a savvy user, they will know that you're intercepting the information.
You can use proxies that just record a person's activity so you can record what is happening and where they are browsing, but really, if you're implementing draconian measures to prevent the possibility that someone's stealing your information, you're probably making a workplace that fosters the kind of attitude that justifies, to the employee, doing this in the first place. And you'll also have to have HR firing policies for cell phones (recording with cameras), USB drives, and maybe making sure they don't memorize things as well.
Anyway, there's no "simple" way to break the HTTPS monitoring without some way of it being discovered unless you simply block outgoing access to that port with a firewall rule or proxy filter. Otherwise the whole point of HTTPS is pointless.
Yes - not only would you need a certificate signed by an authority acceptable to the client but you would also need to poison the DNS for the client or redirect the IP packet stream.
I suspect it may be technically possible to implement an HTTPS proxy which would generate a certificate on the fly signed by a local CA and proxy the requests using that, but very difficult.
If you're concerned about data leaking over HTTPS, just don't allow your users access to HTTPS.
It doesn't solve the problem of them writing stuff down on bits of paper.
The only practical solution is to keep a good audit trail - preferably with honey pots.
The https issue is resolved by the MiM type of solution indeed. Usually it means a proxy is catching outgoing https sessions, and serves those to the user signed by it's own ssl cert, while conducting the https comms towards the outside world on it's own.
The free myDLP solution can do that using it's own config of squid, and the more complex solutions, like Websense and symantec, iirc do the same thing, if slightly more powerful (load balancing between such proxies, fine grained cert management etc...)