Perimeter
6/12/2012
06:45 PM
Connect Directly
RSS
E-Mail
50%
50%

Don't Blame Me, I'm Just An Employee

If you're looking for a cure for mishandling of sensitive data, then look no further than your own management team

Five years ago I remember contemplating some future day when the general workforce would come to understand the importance of securing sensitive data, taking a personal interest -- and even making a personal effort -- in support of that goal. Fast-forward to last week. While reviewing the findings of a customer's data risk assessment, I came to a personal realization: The workforce will never learn.

Not surprisingly, the results of this risk assessment were similar to the dozens before it. Despite the fact that the findings supported the need for my company's products and services, I found myself strangely deflated and disappointed. But there was also another feeling welling up inside me that I couldn't immediately identify. It was something unusual for the situation, a deeper, rawer emotion. Anger. I was officially mad.

I'd been through this process more than 100 times and had never been angry. Yet here I was sitting in front of my customer, seething inside. I couldn't let the anger show, of course, so I shouted in my mind, "Have end users learned nothing in the past five years?" We found incidents of users still sending spreadsheets with personally identifiable information, such as names and Social Security, credit card, and account numbers, to personal email accounts. Customer service reps were still replying to customer email messages in cleartext, leaving credit card numbers, expiration dates, and card security codes in place. Network and workstation drives were still chock-full of interesting and scary sensitive data saved by unwitting end users. And FTP jobs thought to be secure were still transmitting sensitive data in the clear.

As we reviewed the individual incidents and saw the usernames ascribed to each occurrence of data misuse -- billyjones, sallylu, etc. -- my anger toward the end users began to wane. Knowing this particular customer as I do, and the general lack of executive management support for data protection, suddenly it was management I found in my crosshair. A torrent of memories of working with this customer came flooding to my mind. New roadblocks seemed to appear anytime we identified an area of needed improvement. Always willing to talk a good talk, but seldom willing to put their money where their mouths were, my anger and frustration shifted entirely to the management team.

Don't get me wrong; end users must still do their part. In fact, there's a growing awareness for data security among the workforce that will certainly continue to improve. However, as much as we may wish, data security is simply not the mindset of the average end user. The breach news, if they even hear it, doesn't mean anything to them. Whether we like it or not, their focus is on completing their primary job duties, right where it should be. The ultimate responsibility for data security still rests with management.

Management must accept that responsibility and force a shift in corporate consciousness toward data security. This shift begins with attention at the executive level and filters down through the organization by means of those inconvenient data security tasks that are all too often left undone: organized training, internal awareness initiatives, and reinforcement with enforcement technologies. Until management takes action to increase awareness among its workforce, it is difficult to expect a higher level of end user care for sensitive data.

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
senthilkumar@techweb.com
50%
50%
senthilkumar@techweb.com,
User Rank: Apprentice
8/16/2012 | 12:47:48 PM
re: Don't Blame Me, I'm Just An Employee
Excellent Article
Register for Dark Reading Newsletters
White Papers
Flash Poll
Current Issue
Cartoon
Video
Slideshows
Twitter Feed
Dark Reading - Bug Report
Bug Report
Enterprise Vulnerabilities
From DHS/US-CERT's National Vulnerability Database
CVE-2013-6335
Published: 2014-08-26
The Backup-Archive client in IBM Tivoli Storage Manager (TSM) for Space Management 5.x and 6.x before 6.2.5.3, 6.3.x before 6.3.2, 6.4.x before 6.4.2, and 7.1.x before 7.1.0.3 on Linux and AIX, and 5.x and 6.x before 6.1.5.6 on Solaris and HP-UX, does not preserve file permissions across backup and ...

CVE-2014-0480
Published: 2014-08-26
The core.urlresolvers.reverse function in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 does not properly validate URLs, which allows remote attackers to conduct phishing attacks via a // (slash slash) in a URL, which triggers a scheme-relative URL ...

CVE-2014-0481
Published: 2014-08-26
The default configuration for the file upload handling system in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 uses a sequential file name generation process when a file with a conflicting name is uploaded, which allows remote attackers to cause a d...

CVE-2014-0482
Published: 2014-08-26
The contrib.auth.middleware.RemoteUserMiddleware middleware in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3, when using the contrib.auth.backends.RemoteUserBackend backend, allows remote authenticated users to hijack web sessions via vectors relate...

CVE-2014-0483
Published: 2014-08-26
The administrative interface (contrib.admin) in Django before 1.4.14, 1.5.x before 1.5.9, 1.6.x before 1.6.6, and 1.7 before release candidate 3 does not check if a field represents a relationship between models, which allows remote authenticated users to obtain sensitive information via a to_field ...

Best of the Web
Dark Reading Radio
Archived Dark Reading Radio
Three interviews on critical embedded systems and security, recorded at Black Hat 2014 in Las Vegas.