Pavlov Scope

2006 February 11

Q: Locking down to prevent disclosure

Filed under: ITSec — Kev Frey @ 21:13:28

I am in a conundrum: From a technology perspective, how do we prevent confidential company data from being disclosed over the web?

Information leakage, in this sense, is a very difficult problem to solve with certainty. Almost everything is merely a mitigation and nothing is seems to be foolproof or without a way around it. If an organization has decided to provide fairly liberal access to the Web by company employees using company computers, either internal or remote, then preventing the use of “certain” kinds of sites (such as webmail, webstorage, etc.) becomes very difficult.

For example: How to lock down the use of webmail and those free (or cheap) webstorage sites like FreeWebSpace.com, BigVault.com, xdrive.com, ibackup.com, filelodge.com, etc. etc. etc. (I’ve counted more than 20 and that is with a simple, quick Google search)?

Add to the problem, remote users. Other than installing software firewalls with according policy configurations (which is daunting in itself), how does one prevent remote PC users (i.e. users outside of the company network) from utilizing webmail and webstorage services? And, even with software firewalls, if the remote users have Admin rights on their computers, they can delete, disable, or cripple the firewall software (and arguably, need to for interop with the heterogeny of networks and configurations in hotels, hotspots, etc.).

Additionally, dropping access to each and every Internet proxy (used for anonymizing, etc.) which might be used to circumvent company site restrictions is like trying to stop lava flows with a garden hose – akin to putting each spam domain name one encounters in a blocklist individually! Hell, anyone can setup a private proxy and use that to browse the web and it would go undetected for a while before the log pattern of a single site being accessed would emerge.

Another REMOTE user problem:

If one mandates that all users, including remote VPN-attached clients, use the proxy server for Web access. This is to prevent access to webmail, webstorage, anonymizers, etc. type sites to prevent information leakage or outright unlawful and intentional disclosure.

However, this introduces a bit of a problem: Users will be required to connect to the VPN to get access to the proxy server in their web browsers. However, to connect to the VPN from most hotels/hotspots/etc., one must authenticate with the provider’s infrastructure (either to accept charges and/or to accept terms and conditions) via the same web browser. This writes out a session cookie from the provider, which then allows the PC out to the Internet (which then allows VPN, etc.).

The problem is that browsers configured to use a proxy server will not “trigger” the mechanisms generally used by hotels/hotspots/airports/etc. So, we are stuck with a chicken-and-egg problem.

I see two primary ways around this:

1) Determine the URLs / addresses used by a majority of providers, and place those into the “exceptions” list in each of these remote clients to bypass the proxy for those sites (allowing authentication with the local provider’s infrastructure to get a VPN connection, thereby allowing the rest of the Internet sites to route properly through the proxy server).

2) Put the proxy server into a publicly available (non-NAT) DMZ, so that the Proxy server’s IP address is available to both internal and Internet-based clients (this seems less secure).

I ask these questions to determine what technology can be used to construct a policy enforcement system to contain intentional attempts to utilize non-company mechanisms to transfer, share, or store company information assets.

Am I missing something or is this just hard? To me, without spending gobs of money on technology and implementation, this is a question of the classic security vs. usability problem. Is there an enterprise solution for preventing PCs from sending data (preferably policy-based) either via blocking HTTP PUT commands or other methods? Please only consider IP network methods specifically – USB, CDRom, etc. should be excluded from the discussion.

_____________________________________________________________
KevFrey

kevfrey@gmail.com
.     .    .   .  . .. .  .   .    .     .

Leave a Reply

You must be logged in to post a comment.