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.

Risk

7/2/2009
03:15 PM
Art Wittmann
Art Wittmann
Commentary
Connect Directly
LinkedIn
Twitter
RSS
E-Mail
50%
50%

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.

Comment  | 
Print  | 
More Insights
Comments
Newest First  |  Oldest First  |  Threaded View
I 'Hacked' My Accounts Using My Mobile Number: Here's What I Learned
Nicole Sette, Director in the Cyber Risk practice of Kroll, a division of Duff & Phelps,  11/19/2019
DevSecOps: The Answer to the Cloud Security Skills Gap
Lamont Orange, Chief Information Security Officer at Netskope,  11/15/2019
Attackers' Costs Increasing as Businesses Focus on Security
Robert Lemos, Contributing Writer,  11/15/2019
Register for Dark Reading Newsletters
White Papers
Video
Cartoon Contest
Current Issue
Navigating the Deluge of Security Data
In this Tech Digest, Dark Reading shares the experiences of some top security practitioners as they navigate volumes of security data. We examine some examples of how enterprises can cull this data to find the clues they need.
Flash Poll
Rethinking Enterprise Data Defense
Rethinking Enterprise Data Defense
Frustrated with recurring intrusions and breaches, cybersecurity professionals are questioning some of the industrys conventional wisdom. Heres a look at what theyre thinking about.
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2012-1001
PUBLISHED: 2019-11-21
Multiple cross-site scripting (XSS) vulnerabilities in Chyrp before 2.1.2 and before 2.5 Beta 2 allow remote attackers to inject arbitrary web script or HTML via the (1) content parameter to includes/ajax.php or (2) body parameter to includes/error.php.
CVE-2014-8356
PUBLISHED: 2019-11-21
The web administrative portal in Zhone zNID 2426A before S3.0.501 allows remote authenticated users to bypass intended access restrictions via a modified server response, related to an insecure direct object reference.
CVE-2015-3140
PUBLISHED: 2019-11-21
Multiple cross-site request forgery (CSRF) vulnerabilities in Synametrics Technologies SynaMan before 3.5 Build 1451, Syncrify before 3.7 Build 856, and SynTail before 1.5 Build 567
CVE-2019-19207
PUBLISHED: 2019-11-21
rConfig 3.9.2 allows devices.php?searchColumn= SQL injection.
CVE-2019-19203
PUBLISHED: 2019-11-21
An issue was discovered in Oniguruma 6.x before 6.9.4_rc2. In the function gb18030_mbc_enc_len in file gb18030.c, a UChar pointer is dereferenced without checking if it passed the end of the matched string. This leads to a heap-based buffer over-read.