There is this story about an old man who saw a boy looking down at the ground while circling under a lone street light on a dark street. The old man asked the child \u201cwhat happened?\u201d and the child replied \u201cI lost a coin and I am looking for it\u201d. The old man joined the child in looking for the coin and after quite a while of not finding a coin asked the child \u201cwhere have you lost the coin?\u201d to which the child answered \u201cover there\u201d pointing into the dark. \u201cSo why are you looking for the coin here?\u201d asked the old man, and the child answered \u201cbecause it\u2019s dark over there.\u201d<\/p>\n
Why am I telling you this story? Because it keeps popping into my head every time I hear about network-based DLP (data loss prevention). Where is this weird association coming from you ask yourself? I think it\u2019s because today\u2019s DLP solutions try to solve the problem \u201cwhere the light\u201d is rather than where the problem is. You see, virtually all existing network DLP solutions look for data leakage in email traffic (SMTP), instant messenger (IM) and in non-encrypted Web browsing. That\u2019s where the light is\u2026 The real data leakage problem isn\u2019t there, but that does not bother DLP vendors such as Symantec<\/a> and Websense<\/a>. They assume that their customers are like the child in my story. However, given the small size of the DLP market \u2013 which indicates that almost no one is buying their solutions - their assumption is probably wrong.<\/p>\n Okay\u2026 I know. I still need to explain why data leakage is not where the light is. Before that, let me tell you another story. This time \u2013 a real one. Two years ago my company has started signing up resellers in the U.S, so instead of paying money to lawyers for their help, we called a sales guy we new in another company and asked for his reseller agreement. It just so happened that he was working for a DLP company, so he said \u201cI cannot email you the document because our product will stop it, but if you add me as your MSN messenger buddy I will get you the document right away\u201d, which he did.<\/p>\n My point in this story? Looking for data leaks in email, IM and web traffic is easy, but that does not even begin to solve the problem. These are just few applications among the hundreds of application that are capable of file transfer \u2013 peer-to-peer applications, skype, online backup services and gmail to name a few. There are many examples of organizations losing data through peer-to-peer networks, such as Walter Reed<\/a> and the Tokyo Police<\/a> department.<\/p>\n Symantec claims they can scan all TCP traffic. I\u2019m not buying it. They do not decrypt all SSL traffic, cannot look into encrypted peer-to-peer traffic, cannot look inside tunneling applications such as Ultrasurf <\/a>, cannot see into online backup solutions that encrypt the data, cannot control Skype, and so on. I expect a good DLP solution to be able to detect data leakage in all traffic, whether it is encrypted or not and whatever application is being used to transfer the data. And if the DLP solution cannot look into the data because of, for example, custom encryption, it needs to block it. Anything less than that makes it too easy to bypass security controls either intentionally or unintentionally.<\/p>\n Nir.<\/p>\n","protected":false},"excerpt":{"rendered":" Looking for data leaks in email, IM and web traffic is easy, but that does not even begin to solve the problem. These are just few applications among the hundreds of application that are capable of file transfer \u2013 peer-to-peer applications, skype, online backup services and gmail to name a few. There are many examples of organizations losing data through peer-to-peer networks, such as Walter Reed<\/a> and the Tokyo Police<\/a> department.<\/p>\n","protected":false},"author":40,"featured_media":0,"comment_status":"open","ping_status":"open","sticky":false,"template":"","format":"standard","meta":{"_jetpack_memberships_contains_paid_content":false,"footnotes":""},"categories":[5],"tags":[39],"coauthors":[],"class_list":["post-79","post","type-post","status-publish","format-standard","hentry","category-firewall","tag-data-leakage"],"jetpack_featured_media_url":"","jetpack_sharing_enabled":true,"_links":{"self":[{"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/posts\/79","targetHints":{"allow":["GET"]}}],"collection":[{"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/posts"}],"about":[{"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/types\/post"}],"author":[{"embeddable":true,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/users\/40"}],"replies":[{"embeddable":true,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/comments?post=79"}],"version-history":[{"count":1,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/posts\/79\/revisions"}],"predecessor-version":[{"id":944,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/posts\/79\/revisions\/944"}],"wp:attachment":[{"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/media?parent=79"}],"wp:term":[{"taxonomy":"category","embeddable":true,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/categories?post=79"},{"taxonomy":"post_tag","embeddable":true,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/tags?post=79"},{"taxonomy":"author","embeddable":true,"href":"https:\/\/www2.paloaltonetworks.com\/blog\/wp-json\/wp\/v2\/coauthors?post=79"}],"curies":[{"name":"wp","href":"https:\/\/api.w.org\/{rel}","templated":true}]}}