I'm trying accomplish the following mission:
1. Block users (w/o Justification) from posting sensitive data on any web server outside of our network (Facebook, for example)
2. Monitor users when they post sensitive data on internal web servers (HR and Financial systems).
So I created two web destinations - "External Sites" and "Intranet Sites", and I added my internal webservers to the "Intranet Sites" destination (names have been excluded from the screenshot).
The problem is how do I create a web destination object that represents the entire Internet AND excludes my Intranet servers. I can configure the rule to monitor a web destination object or all web servers, which means I am able to configure a monitor rule for "Intranet Sites" but...
...if I configure the "External Sites" destination object to use the Any Web Destination check box, then it's going to include my Intranet sites by default, which if I understand the HDLP rules correctly (I'm relatively new to HDLP), means my Intranet sites will get monitored and blocked because the destination belongs to two different rules.
Make Sense? Any thoughts on this?Message was edited by: BionicSecurityEngineer on 7/27/10 10:05:57 AM CDT
I talked to support and this configuration is simply not possible, and I'm not the only person asking for it, so I predict we'll have this capability in the near future.
Now, we did cook up an idea to use whitelisting and a blocking rule that might work. I'm testing it now, and I will post results soon.
We solved this by relying on FQDN (fully qualified domain name).
1) Create a Web Destination that includes your companies domain name(s).
2) Uncheck these entries.
3) Check the "Other web server" entry.
Using this Web Destination, we can create Web Post Protection Rules that only apply to Internet domains.
Of course, if a user visits http://intranetsite instead of http://intranetsite.domain.net, this method won't be effective. We're using this setup to block traffic... so if the request doesn't contain the FQDN, the user doesn't get access at all.
Interesting solution, and I can see where someone attempting to "circumvent security" by using a server name would be blocked. I like that. Have you played with the white list yet? My only concern about the whitelist is that it may not monitor activity, but we'll find out tomorrow.Message was edited by: BionicSecurityEngineer on 7/28/10 8:21:12 PM CDT
Have we found any workaround or any feature addition to DLP around this issue as of now? My requirement is exactly the same as that of BionicSE. however, the solution provided by sprairie would not work in our environment as we block users from using the servername to access the link.
So is there a way that we can whitelist local / custom application?