Dark Reading is part of the Informa Tech Division of Informa PLC

This site is operated by a business or businesses owned by Informa PLC and all copyright resides with them.Informa PLC's registered office is 5 Howick Place, London SW1P 1WG. Registered in England and Wales. Number 8860726.


03:15 PM
Art Wittmann
Art Wittmann
Connect Directly

Practical Analysis: Why Aren't We Better At Protecting Data?

Knowing where your peers have failed to protect data is the first step in crafting an effective data protection policy.

We're not as good as we should be at handling sensitive data. One strong data point toward that conclusion comes from the watchdog site Privacy Rights Clearinghouse (www.privacyrights.org), which has been doing its best to track both the cause and effect of data breaches since 2005. Since then, the site has cataloged more than 262 million compromised records. Some are more severe than others, and some have been handled better than others, but that grand total should serve to verify my basic thesis: As a group, we aren't very good at this.

There's no particular group of institutions that fare worse on this list than another-- banks, state governments, federal agencies, educational institutions, insurers, healthcare organizations, and all other manner of businesses show up. What's striking about the list is that a large number of breaches result from simple theft, and from either poorly devised or poorly implemented policies. For these sorts of breaches, tighter regulation typically isn't the answer, and technology is only part of the answer.

Clearly, if systems with sensitive data are stolen from public places--one of the more common methods for exposures--there are policy issues, training issues, and technology issues at hand.

Do your policies allow for users taking significant numbers of sensitive records outside of the relative safety of your corporate walls? Maybe that's not such a good idea. If it's truly necessary, are your users adequately and regularly trained in how to keep that data safe, and have you employed the right technologies--like encryption--that will allow you to put some technical muscle behind your policy?

In our recent survey and report (available at dataprotection.informationweek.com) on data loss prevention, we found organizations still applying relatively the same policies to all users. At the same time, well over half have not yet implemented any form of encryption on mobile devices. Let's face it, if you're still more worried about whether Ed in accounting changes his password monthly to something longer than 12 characters with alpha, numeric, and punctuation symbols and is otherwise impossible for Ed to remember, while your sales team is running around with unencrypted client data on their laptops, something is very wrong with your data protection policies. To put it plainly, you're doing what's easy and cheap for you, but not what's in the best interest of the business and its customers.

Other discontinuities between policy and risk aren't hard to find. Poll respondents worried most about e-mail as a mechanism for losing sensitive data (47%), followed by removable media (32%); however, almost half don't encrypt sensitive data on removable media. It's a disaster waiting to happen, and the only thing worse than losing sensitive data is losing it and not knowing that it's gone. Here, too, it's a matter of policy, training, and technology. Log analysis software along with a policy and practice of actually using it is critical for protecting sensitive data.

Common sense and awareness of risks will go a long way in guiding DLP policies.

Art Wittmann is director of InformationWeek Analytics. Write to him at [email protected].

To find out more about Art Wittmann, please visit his page.

Register to see all reports at InformationWeekAnalytics.com.


Recommended Reading:

Comment  | 
Print  | 
More Insights
Newest First  |  Oldest First  |  Threaded View
COVID-19: Latest Security News & Commentary
Dark Reading Staff 7/14/2020
Omdia Research Launches Page on Dark Reading
Tim Wilson, Editor in Chief, Dark Reading 7/9/2020
Register for Dark Reading Newsletters
White Papers
Current Issue
Special Report: Computing's New Normal, a Dark Reading Perspective
This special report examines how IT security organizations have adapted to the "new normal" of computing and what the long-term effects will be. Read it and get a unique set of perspectives on issues ranging from new threats & vulnerabilities as a result of remote working to how enterprise security strategy will be affected long term.
Flash Poll
The Threat from the Internetand What Your Organization Can Do About It
The Threat from the Internetand What Your Organization Can Do About It
This report describes some of the latest attacks and threats emanating from the Internet, as well as advice and tips on how your organization can mitigate those threats before they affect your business. Download it today!
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
PUBLISHED: 2020-07-16
IBM Sterling External Authentication Server 6.0.1, 6.0.0,, and 2.4.2 and IBM Sterling Secure Proxy 6.0.1, 6.0.0, 3.4.3, and 3.4.2 are vulnerable to an XML External Entity Injection (XXE) attack when processing XML data. A remote attacker could exploit this vulnerability to expose sensitive i...
PUBLISHED: 2020-07-16
IBM Team Concert (RTC) is vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 172887.
PUBLISHED: 2020-07-16
IBM Jazz Team Server based Applications are vulnerable to cross-site scripting. This vulnerability allows users to embed arbitrary JavaScript code in the Web UI thus altering the intended functionality potentially leading to credentials disclosure within a trusted session. IBM X-Force ID: 173174.
PUBLISHED: 2020-07-16
MIT Lifelong Kindergarten Scratch scratch-vm before 0.2.0-prerelease.20200714185213 loads extension URLs from untrusted project.json files with certain _ characters, resulting in remote code execution because the URL's content is treated as a script and is executed as a worker. The responsible code ...
PUBLISHED: 2020-07-16
ConnectWise Automate through 2020.x has insufficient validation on certain authentication paths, allowing authentication bypass via a series of attempts. This was patched in 2020.7 and in a hotfix for 2019.12.