Perimeter
11/15/2012
02:10 PM
Connect Directly
RSS
E-Mail
50%
50%

All Security Technologies Are Not Data Loss Prevention

While security technologies may share the common goal of protecting an organization's sensitive data, not all can -- or should -- be called data loss prevention

I recently read an article that made the following assertion (paraphrased in my words): Every part of an organization's security technology arsenal is, in fact, data loss prevention (DLP). At the very heart of every organization's information security strategy is the blessed data, the object of the safeguarding effort. Any and every security tool or technology that serves to protect that data, therefore, can be deemed DLP.

One example in the article suggests that disk encryption could very well be DLP to an organization with a mobile workforce because both technologies share the objective of data protection. If that logic holds true, then we might as well drop in uninterruptible power supplies and data recovery services to the growing list of DLP products because each one helps protect data. Why not add laptop privacy screen filters and portable hard drives, while we're at it? In fact, let's drop in all 3,009 products once listed on the website of an office supply giant in its innovative "DLP" category.

Of course, I'm being facetious to emphasize my point. The unfortunate reality is the marketplace is flooded with "data loss prevention" tools that wouldn't know sensitive data if it bit them in the power cord. Where should we draw the line?

While all security technologies may share the same objective of protecting an organization's critical data, different tools arrive at that objective from different angles, often using completely different technologies. Those different technologies require unique labels in order to distinguish one technology from another. (Imagine a world where all security technologies were referred to as "data loss prevention.")

Those who share the "all-security-is-DLP" mindset seem to disregard this point, claiming that any security tool can be DLP to one organization, while a different security tool can be data loss prevention to another organization. I agree that DLP often has different meanings to different people.

The problem I have with this approach is: I do not agree this should be the case.

While most of us can agree that data protection is the overarching goal of information security, the reality is very few information security defenses work at the data level. DLP technologies deliver something that other data protection tools do not -- and simply cannot: They monitor the actual data, detecting and preventing the leakage of that sensitive data. What's more, true DLP technologies accomplish this colossal task comprehensively, through deep packet inspection, using a high level of content-awareness across all major leakage vectors: data in motion at the network gateway, data in use at the endpoint and data at rest in storage.

For years, many argued the phrase "data loss prevention" was too broad and did not accurately describe the true benefit of these technologies. I would argue an even more significant problem is the generally accepted notion that data loss prevention is a product, rather than the complete process of safeguarding data. Regardless of how I feel about these arguments, both are now rendered moot. It's too late to turn back the clock. The marketplace has spoken definitively: DLP is the descriptive term for that category of solutions that prevent the leakage of sensitive data.

By accepting and promoting this reality, the marketplace -- and specifically those organizations with data protection needs -- will better understand how to meet requirements with the right tools for the greatest data protection benefit.

Jared Thorkelson is founder and president of DLP Experts, a vendor-agnostic VAR and consulting practice focused exclusively on data protection. He can be reached at jthork@dlpexperts.com Jared is president of DLP Experts, a value-added reseller dedicated exclusively to data loss prevention (DLP) and other data protection technologies and services. For over twenty years Jared has held executive level positions with technology firms, with the last six years ... View Full Bio

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
ANON1233964134849
50%
50%
ANON1233964134849,
User Rank: Apprentice
11/16/2012 | 3:39:32 AM
re: All Security Technologies Are Not Data Loss Prevention
Core Technology of DLP - Protection of the Data (regardless of the device or file) -á http://www.gtbtechnologies.com...
Register for Dark Reading Newsletters
White Papers
Cartoon
Current Issue
Dark Reading Must Reads - September 25, 2014
Dark Reading's new Must Reads is a compendium of our best recent coverage of identity and access management. Learn about access control in the age of HTML5, how to improve authentication, why Active Directory is dead, and more.
Flash Poll
Title Partner’s Role in Perimeter Security
Title Partner’s Role in Perimeter Security
Considering how prevalent third-party attacks are, we need to ask hard questions about how partners and suppliers are safeguarding systems and data.
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-5485
Published: 2014-09-30
registerConfiglet.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via unspecified vectors, related to the admin interface.

CVE-2012-5486
Published: 2014-09-30
ZPublisher.HTTPRequest._scrubHeader in Zope 2 before 2.13.19, as used in Plone before 4.3 beta 1, allows remote attackers to inject arbitrary HTTP headers via a linefeed (LF) character.

CVE-2012-5487
Published: 2014-09-30
The sandbox whitelisting function (allowmodule.py) in Plone before 4.2.3 and 4.3 before beta 1 allows remote authenticated users with certain privileges to bypass the Python sandbox restriction and execute arbitrary Python code via vectors related to importing.

CVE-2012-5488
Published: 2014-09-30
python_scripts.py in Plone before 4.2.3 and 4.3 before beta 1 allows remote attackers to execute Python code via a crafted URL, related to createObject.

CVE-2012-5489
Published: 2014-09-30
The App.Undo.UndoSupport.get_request_var_or_attr function in Zope before 2.12.21 and 3.13.x before 2.13.11, as used in Plone before 4.2.3 and 4.3 before beta 1, allows remote authenticated users to gain access to restricted attributes via unspecified vectors.

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
In our next Dark Reading Radio broadcast, we’ll take a close look at some of the latest research and practices in application security.