Sensitive data can be tunnelled out of your network in many ways. Fortunately, there are just as many ways to stop it.
It gets harder and harder to simply steal data from a business. The insider is clearly a significant threat, so you've probably installed USB port control software to prevent theft on USB sticks and similar media.
Maybe you've even given thought to stopping tools that can be used to work around USB port control, such as the Teensy keylogger project? (See www.pjrc.com/teensy and irongeek.com.)
It's going to be difficult to stop the user physically printing data, though getting large amounts of data out that way would be tricky.
What about tunnelling the data out of your network, encrypting the contents of the tunnel so that you haven't a clue what's being stolen?
My original interest in tunnelling was around getting internet access from wireless hotspots for free. The hotspot has to offer DNS in order to resolve, say, www.btopenzone.com to a usable IP address. Tools such as iodine can be used to encapsulate traffic into DNS requests. Simply set up a listening server back home, which re-assembles your traffic, then out on to the internet. A DNS request type such as CNAME is ideal for dropping your HTTP traffic into.
Unfortunately, DNS tunnelling can be slow, but it does work. Also, the tools haven't been updated in a long time, probably because mobile data is that much faster and cheap to use. One simple route to make DNS tunnelling out of your business much harder is to block DNS requests at your outbound proxy, and force all DNS resolution requests via your internal DNS server.
Probably the easiest form of tunnelling is SSL. The client machine on your network establishes an SSL encrypted connection with a server on the internet, and you will struggle to read the traffic. OpenVPN is probably the easiest example, though there are numerous other ways to tunnel over SSL.
One route to defeat this is to ‘bridge' or inspect all SSL connections, rather like a man-in-the-middle attack. There are several commercial products that offer this, though you won't be popular if you're inspecting your users' online banking sessions.
Tunnelling traffic outbound over common ports is less likely to be spotted; TCP 80 and 443 being ideal candidates, as you'll find it hard to deny web browsing to the business. An interesting new tool called Scotty has just been released that creates an encrypted tunnel over HTTP. While there's nothing particularly new about the concept, the implementation is rather nice: very lightweight, strong encryption and use of simple HTTP.
How about Skype? File transfer within the Skype chat client is considered pretty secure, so no wonder that organisations are bothered by it. There are also all sorts of video-conferencing applications that can be used to transfer files over encrypted tunnels.
IPv6 tunnels are interesting also – Teredo tunnelling is about encapsulating IPv6 traffic in IPv4. It can result in an internal client having a publicly routable IPv6 address. Unless you've explicitly blocked IPv6 and/or Teredo tunnels, it can be hard to block this traffic.
It's almost impossible to mitigate all tunnelling routes; even really simple timing-based attacks at protocol level can be used to export data, albeit extremely slowly. Then again, if no one is ever going to notice your tunnel, who cares how slow it is?
In general, you should deny all outbound traffic at your perimeter systems, other than for traffic that is explicitly required by the business. For protocols you can't block, route them through a proxy and monitor them carefully. Finally, for protocols that are encrypted, consider whether you can intercept or bridge the traffic.
One last thought: if someone is trying to tunnel data out of your network, they'll probably want to hide the true address of the other end of the tunnel. It would be a good idea to block the public IP addresses of known Tor endpoints at your perimeter systems. It doesn't stop tunnelling, but it does make it harder to conceal.